I sent the following information to Rob yesterday. Should have sent it to
the list, but it was relevant to a conversation we had during the sprint.
Here's what I'm doing ...
>
> When I add a set_trace() to the end of the addMember() method within the
> base layers setup, I get the following proof of password on the member
> "portal_member":
>
> > /usr/local/zope/sprint/remember-instance/Products/remember/tests/base.py(87)addMember()
>
> -> return mem
> (Pdb) mem.getEmail()
> 'noreply@...'
> (Pdb) mem.getPassword ()
> 'hmac_sha:0ebb57dd8fc590bbcf976b028e873fe804b9df60'
>
>
> Later on in the process, when I add a set_trace() into the
> test_deleteMembers() method of TestMembershipTool():
>
> (Pdb) guy = self.mtool.getMemberById('portal_member')
> (Pdb) guy.getPassword()
> 'hmac_sha:0ebb57dd8fc590bbcf976b028e873fe804b9df60'
>
>
> Okay, still a password. When you dig into the innards of PAS, you get to
> the following:
>
> >
> /usr/local/zope/sprint/remember-instance/Products/PluggableAuthService/plugins/ZODBUserManager.py(303)removeUser()
> -> def removeUser( self, user_id ):
> (Pdb) s
> >
> /usr/local/zope/sprint/remember-instance/Products/PluggableAuthService/plugins/ZODBUserManager.py(305)removeUser()
>
> -> if self._user_passwords.get( user_id ) is None:
> (Pdb) print user_id
> portal_member
> (Pdb) self._user_passwords.get( user_id )
>
>
> None! WTF!?! Maybe I'm reading too much into the _user_passwords
> attribute. self._user_passwords is some BTree object, which I don't really
> have too much experience interacting with unfortunately, but "new_member"
> returns a non-None value avoiding the raised KeyError. "portal_member"
> returns None and halts there.
>
> To the best of my understanding, the member created within
> test_deleteMembers of the TestMembershipTool class with the following
> syntax:
>
> self.mtool = self.portal.portal_membership
> self.mtool.addMember ('new_member', 'secret', ('Member',), tuple)
>
> is perhaps wrapped around the user object and thus is similar enough to
> what the ZODBUserManager expects to interact with, but ultimately defers
> deletion to membrane's implementation of IUserManagement.
>
> By contrast, "portal_member", which is created in base.py is some more
> limited object for some reason or another. I don't have the experience or
> context to understand this at this point, but a simple __dict__ on each of
> these member objects turns up quite a few differences.
>
> The obvious solution is just to move membrane_users above source_users
> within the IUserManagement plugin via a setuphandler. But that feels kind
> of like cheating
>
>
Perhaps that gives you at least some insight.
Look for me on IRC if you'd like to discuss.
Cheers, Andrew
On 10/31/06, Jeff Hammel <jhammel@...> wrote:
>
> Hi Andrew,
>
> Rob Marianski + myself are also working on the deleteMembers problem. See
> issue #15 under the tracker. Note that this seems to be a issue with the
> live site, not just a test failure.
>
> Let us know if you know a good direction to work on this from. We're
> trying to avoid putting the deleteMembers code back in remember's membership
> tool, but are looking at the member creation process to see how base.py's
> addMember function and the web-based factory methods differ from the
> membership tool's way of adding a member, which doesn't successfully delete.
>
> So far, progress is slow.
>
> Jeff
>
> On Tue, Oct 31, 2006 at 10:01:18AM -0800, Andrew Burkhalter wrote:
> > On 10/30/06, Brian Gershon <briang@...> wrote:
> > >
> > >Hey Andrew,
> > >
> > >Yes, in Plone 3.0 "named adapters" were breaking the tests.
> > >
> > >(My understanding is that named adapters are adapters that require
> > >parameters, and the tests weren't passing any parameters so they were
> > >giving
> > >some sort of unsupported Interface error)
> > >
> > >Maybe (for 2.5) this code needs to be wrapped with another "if" (was it
> > >giving an attribute error or something based on .name?) so that it
> doesn't
> > >break in 2.5. I wasn't able to unit test in 2.5 since the tests were
> > >broken - giving us an infinite loop of unit testing fun :)
> >
> >
> > Well, if you're feeling ambitious and would like to put this code back
> into
> > membrane, you can also test in the Plone 2.5 branch. See the exact
> testing
> > platform in the thread below. As of this point, you should only see to
> 2
> > assertion errors showing that I believe copy and cut don't work and one
> > failure associated with the deleteMembers test. The latter I'm working
> on
> > and hope to get Rob's eyes on things.
> >
> > How about we make a note about this in the ReMember Issue Tracker so we
> can
> > >continue to play with this down the road after the tests are working -
> then
> > >we can make sure it works on both 2.5 and 3.0.
> > >
> > >I'll go ahead now and create an entry in the Tracker for this...
> >
> >
> > Fantastic. Thanks Brian.
> >
> > Cheers, Andrew
> >
> >
> > >On 10/30/06, Andrew Burkhalter < andrewburkhalter@...> wrote:
> > >>
> > >> First off, my platform:
> > >>
> > >> - zope 2.9.5
> > >> - Plone 2.5 development branch
> > >> - remember trunk
> > >> - membrane trunk
> > >>
> > >> Upon seeing the remember tests completely crash and burn at the
> > >> RememberProfileLayer as well as basic add new user support TTW
> broken,
> > >I've
> > >> backed out the following code from membrane/tools/membrane.py, which
> were
> > >> added in attempt to support the Plone 3.0 developer branch:
> > >>
> > >> # avoid checking 'named' adapters
> > >> if adapter_reg.name:
> > >> continue
> > >>
> > >> Once completed, we're back to the two assertion errors and one
> failure.
> > >>
> > >>
> > >> I'm not sure what's going on here, so hopefully briang has joined
> this
> > >> list and can shed some light on the subject. I've kept the code
> intact
> > >> within a comment and added a bit of my own thoughts, but for now
> thought
> > >it
> > >> was a priority to get this working on our primary platform at this
> point
> > >and
> > >> also to save others a lot of head scratching. Sorry if I'm missing
> > >> something obvious or not understanding something.
> > >>
> > >> Please post to the list if you have any thoughts, questions about
> this.
> > >>
> > >> Cheers, Andrew
> > >>
> > >>
> > >
> >
> >
> > !DSPAM:1015,45478fcb43051365099012!
>
> --
> To unsubscribe send an email with subject unsubscribe to
> remember@....
> Please contact robm@... for questions.
>
text.html (text/html) 8.6 kB