[Zope3-dev] logout patterns: a small proposal

[Gary Poster]

There are a surprising number of components in zope.app designed to  
help with logging out.  They are all trying to solve the problem that  
some authentication can't log out, so you shouldn't show logout links  
then.

I only care about the pluggable auth in zope.app.authentication.   
Therefore what I want is a way to determine whether the credentials  
plugin used supports logout.  I want this to be dynamic, responding  
to TTW configuration of the pluggable auth, which the current  
zope.app solutions are not.

Jim suggested that a subscriber to principal creation event might  
scribble an attribute on the (transient) principal object that  
indicated that the credentials plugin used to create the principal  
supported logout.  This would be easy to do, light-weight, robust  
(i.e., even in the face of multiple active credentials plugins),  
something that I could do without committing the zope project to the  
solution, and easy to use (my tal could do something like  
"""tal:condition="request/principal/canLogout|nothing""").

The problem is that the principal creation event does not include the  
credentials plugin used by the authentication.

The easiest way to approach this, given the current pluggable auth  
design, is to add a 'credentialsPlugin' attribute on the info object  
passed to the principal creation factory.  The 'credentialsPlugin'  
attribute would have a reference to the credentialsPlugin used, and  
would be assigned by the authentication utility.  This is a solution  
because the event fired already includes the info object.

Pros:
- It enables a more dynamic and much simpler story for determining  
whether an app can support logging out than the current pertinent  
zope.app code (as long as you only use pluggable auth).
- It's a one-line change to the code itself (not including interface  
and test changes).  No grand architecture changes.
- the 'info' object seems to be a reasonable place to add information  
about the process used to create the principal.
- It's ignorable, for those that wish to ignore it.

Cons:
- This is the only use case I know of for the behavior, so it has a  
small feel of 'scratch an itch'.  Maybe that's not too bad here.

Thoughts?

Gary