[Zope3-dev] logout patterns: a small proposal

[Sidnei da Silva]

On Thu, Dec 08, 2005 at 10:11:46AM -0500, Gary Poster wrote:
| 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.

Sounds good to me.

Only one issue that you should have in mind, and that has bitten me
several times with the Zope 2 PluggableAuthService is the following:

If you use the 'HTTPBasicAuthHelper' for login, that doesn't mean you
can use it for logout. That is specially true if you happen to use the
'CookieAuthHelper', which translates cookie-based credentials to http
basic.

What happens is that it in PAS, if you call logout() it will call all
the 'ICredentialsReset', however if the HTTPBasicHelper happens
to be one of those, it will raise a 'Unauthorized' exception, because
that's how you log someone out using http basic auth, and then two
things happen:

1. The cookie credentials don't get erased because of the Unathorized
2. Any plugins that happened to be enabled for ICredentialsReset won't
   fire.

Hope that helps,

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com