[Zope-PTK] LoginManager (was Re: Stability rule-of-thumb (fwd))

[Phillip J. Eby]

At 02:54 PM 2/6/00 -0500, Mike Pelletier wrote:
>
>    For those just tuning in: with this scheme, you cache the user's
>identity but not credentials in browser cookies.  This is sufficient for
>them to appear 'logged in' and do most portal tasks, but if the user
>attempts to do something more sensitive (like create or edit an object, or
>view/change their profile data) it pops up a login window to finish
>authenticating the user.
>
>    The last-tried LoginMethod would look for just the identity cookie.  
>Instead of returning the actual User, it would return something that looks
>like the user, but with Anonymous privelages and no sensitive data.  When
>the user attempts to do something sensitive,
>
>  That would allow the user to work on the portal with their customization
>settings without logging in.  When they try to do something sensitive, a
>password propt pops up, and an earlier LoginMethod will begin returning
>their actual User object.  

Sounds like it could work quite well, at least in principle.  If you wanted
to use the "forbiddenPage" hook with this, you might need to have it
explicitly check for one of these unauthenticated-user objects, and just
return so that the LoginManager falls through to the login method.  The
tricky bit that I see is getting at the property sheets, since those are
managed by the user source, not the login method.  I guess you could just
return a proxy wrapper over the user which overrode its getRoles() method.
But then there is the issue of how you would ever show the user links to do
things which they don't have logged-in permissions for, since such things
are usually filtered out of view...

Anyway, speaking of PropertySheets, I have been banging my brain up against
the OFS.PropertySheets module for the past hour or so with only limited
success.  It appears that the OFS.PropertySheets concept of
"propertysheets" isn't quite the same as the ZClass notion of
"propertysheets".  The former supports a sequence interface coupled with a
mapping-interface "get" method, while the latter wants to do
propertysheets.sheetname.  Huh?  Plus, I see what look to me like plain ol'
bugs in OFS.PropertySheets, suggesting that the code in question isn't
actually used.  For example:

    def delPropertySheet(self, name):
        result=[]
        for propset in self.aq_parent.__propsets__:
            if propset.id != name and  propset.xml_namespace() != name:
                result.append(propset)
        self.parent.__propsets__=tuple(result)

The last line seems to be a typo or leftover cruft from a previous
implementation approach.

Anywho, I think I have a general idea of how to implement a propertysheet
delegation protocol, but the devil is in the details: specifically, what
parts of the "propertysheets" object need to be supported.  Mike, can you
tell me what the PTK needs, and/or point me to someone in DC who knows what
the rest of Zope does with the propertysheets attribute?  Thanks.