[Grok-dev] Grok UI Manager Logout

Uli Fouquet uli at gnufix.de
Wed Aug 10 05:53:02 EDT 2011

Hi Paul,

paul wrote:

> On 09/08/2011 15:37, Uli Fouquet wrote:
> > The problem with the mentioned approach, if I understood it correctly,
> > is that it only 'logs out' someone for the mentioned view.
> Miguel's approach is to challenge the browser with a 401 for a different 
> realm than the one used by the manager interface.

Yes, that was mainly in reply to Sebastians wish to make the admin UI
implement it. Therefore I took the liberty to try the approach with the
'Zope' realm. The result is as expected: if I protect a
localhost/myapp/view1 page and do 'logout' on it, I can still access
localhost/, localhost/myapp/otherview, etc. That is not exactly, what I
would expect from a logout ;)

> I'm no expert on basic auth here,

Me neither, really.

> but I believe the browser keeps a 
> site/realm/credentials table available which, if there is a match, 
> allows the browser to re-use the credentials to re-authenticate whenever 
> it needs to.  The act of prompting the browser to fail authentication 
> appears to clear the table entry.  From what I understand, the browser 
> keeps one active realm per site, and one browser instance cannot be 
> authenticated with more than one realm for the same site.

Well, from http://www.ietf.org/rfc/rfc2617.txt , section 2, I learn that

  "A client SHOULD assume that all paths at or deeper than the depth of 
   the last symbolic element in the path field of the Request-URI also
   are within the protection space specified by the Basic realm value of
   the current challenge."

That would mean that if I protect http://localhost/myapp/index, I have
to do that again for http://localhost/myapp/fancystuff and so on, until
a user really requests http://localhost/myapp/ (which then _should_
protect the complete 'deeper' tree of possible URIs).

You might also notice that the above HTTP specification says nothing
about 'forgetting' basic auth credentials. It only tells that this is
mainly a client thing which is bad enough for a server software. So,
it's up to the browser.

Okay, but let's think about grokui.admin doing this approach anyway.
Overall, it looks like implementing the whole thing in
grokui.admin/grokui.base where we have access to the 'index' view of the
root could do the trick, right? Logging out from http://localhost:8080/
then should give the basic-auth login widget popping up whenever this
specific user tries to access some protected page from localhost, right?

Unfortunately this is only partly the case. It seems to work with
Firefox but it doesn't work for example with the (outdated, I admit)
Opera version I have installed locally. With it I can still access
subpages as zope.manager, even if I logged out from
http://localhost:8080/ using Miguels hack. And by doing so, Opera does
not violate the HTTP specification. In other words: sending 401 and
hoping that the client forgets all auth-infos seems not to be safe.

Furthermore you bypass the Zope authentication system with its security
policy and might run into further, difficult to spot security problems.

For that reasons I wouldn't really like to see that 'feature' in grokui.
For real session-based authentication (with logout and all that) I would
instead recommend an own PAU  with sessions, cookies and login-screens.
That not only works consistently on different browser types and is more
secure, it also simply looks better ;)

If we could simplify that task with Grok, I'm really willing to help.
Please just tell, what kind of improvements you could imagine. How
should a really simple authentication setup look like (code-wise) from
your point of view? What are the main problems?

For people really having problems with basic auth logout that use
Firefox, maybe the Web Developer extension is a solution:


or this add-on:


They provide deletion of HTTP basic auth caches on request. And they
work for all sites that use basic auth, not only Grok/Zope/Bluebream.

> Regarding implementing Miguel's browser challenge in the manager 
> interface? Perhaps it's not necessarily a good idea.  It could cause 
> conflict with application PAU implementations.  It's easy enough to 
> implement in the app if necessary- once one knows about this approach.

Right, if you know what you do and are aware that it might not work with
all browsers, I'd agree :)

Best regards,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20110810/e3e4c3dd/attachment.bin 

More information about the Grok-dev mailing list