[Grok-dev] Grok UI Manager Logout

[paul]

On 10/08/2011 11:53, Uli Fouquet wrote:
> 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.
I beg to differ...

>> 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."
It's a bit confusing- to me at least.  Assuming the root of the 
traversal tree is protected; Does that mean that elements beneath the 
root cannot carry different protection than that of the root, or does it 
mean that the root elements protection extends and supplements that of 
the sub-elements?

One thing did strike me; what would be the effect, were one to cycle the 
value of the 'Basic realm' for the same url?
eg:
    Server                                         Browser
~~~~~~                                ~~~~~~~~

<--------     Request http://
    401: realm="Zope"   ------->
<-------      Base64Cred
    htmldata                    ------->
<time passes>
<------       Logout URL
   (Set session flag, Redirect root)
    301:   Redirect           ------->
<--------     Request http://
   (Check session flag, reset flag)
    401:realm="Invalid" ------->
<------       Re-prompt user (cannot find realm=Invalid for "current 
challenge")

> 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.
That's the crux of it, certainly.  And different browsers do whatever 
they think is best given lack of specification.  So there's no 
consistent behaviour we can rely on.

> 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.
Precisely.  At least keep the manager interface behaviour consistent 
across browsers.  It's not really that much of a problem, as such, more 
of an irritation.  The fact that the manager i/f uses basic auth doesn't 
affect the site users at all, just the person managing it.  So, for 
arguments sake, were you to change the manager i/f in some way, the 
change would be affecting only the site developers anyway.  There's 
probably better use for your time.

I would argue that it's probably worth documenting the issue though, 
which is in a way what we are doing right now.

> 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?
And that's the real question.  After understanding the issue, what can 
be done about it?  As far as I can see, so long as the Grok-UI uses 
basic auth (and there's a good reason for that as I understand), and 
browsers don't behave consistently regarding 'forgetting' creds, there's 
not much that can be done at a general level.  Perhaps someone else has 
some bright spark ideas, but I'm all out :-)

Kind regards, and thanks for your in-depth response to this question,

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: prsephton.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20110810/51169519/attachment.vcf