Lennart Regebro wrote:
Supposedly you would not be able to access that part of the site until
you authenticate against it. Isn't that the case now?


Assuming it requires authentication, yes.

And if it doesn't require authentication?

It would fail, since you supplied incorrect authentication. That's pretty counter-intuitive. You are logged in, and click on a part of the site where you should not need authentication, and you get authentication errors. ;)

Indeed. So, this explains the reason why incorrect auth credentials result in an anoymous user rather than an auth failure. Read that way, I think it should stay that way, unless anyone can suggest anything better.
However, it might help if whoever's "in" this code currently adds a big comment explaining the reasoning. Sidnei?


Also, what determines whether it requires authentication? authorisation
requirements or something else?

If it's accessible by anonymous that is the same as not requiring authorization.

I don't think that's the case. I have a specific requirement on the project I'm currently working on to know who the current user is, even if the something is anonymously accessible.


Perhaps userfolders should have the opportunity to do something as they're traversed through to authenticate, rather than waiting until something that requires authorisation kicks them off?

The main problem here is that Internet Explorer doesn't allow you to
log out, for example.

I thought returning enough 401's usually prompts any browser to drop its basic auth?

Nope, not IE. Yes, that is non-standard.

Are you sure? I'm pretty sure I remember the ZMI's "logout" link working in IE, and that relies on returning 401's...


But they do that so that if
you click on something that you can NOT access, you can continue
surfing without having to log in again. Which actually is pretty
reasonable in a way.

...not if they don't also provide a method to consciously drop basic auth headers ;-)


403 Forbidden: The server understood the request, but is refusing to
fulfill it. Authorization will not help and the request SHOULD NOT be
repeated. If the request method was not HEAD and the server wishes to
make public why the request has not been fulfilled, it SHOULD describe
the reason for the refusal in the entity. If the server does not wish
to make this information available to the client, the status code 404
(Not Found) can be used instead.

I fail to see how this is a reasonable resonse when you request a page
that is public just because your credentials are invalid in that
location. It's a bit like refusing people into a public park because
they have a security badge on their shirt. ;)

Well, I have to say I was really disappointed when I read the W3C specs for response codes. They freely interchange authentication and authorization, which are two totally different concepts :-(


However, yes, I agree your use case is important, particularly for Zope with it's devolved idea of user management, and so am now against the change Sidnei was suggesting...

cheers,

Chris

--
Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Reply via email to