Re: [Zope-dev] Authentication Patch
Evan Simpson wrote I got tired of dealing with the weird mechanics cookie-based logins have to deal with, where standard_html_error and tracebacks intrude on login intercepts. I came up with the following minor change, which works great for me, and might make GenericUserFolder's job easier, too.
In ZPublisher/HTTPRequest.py (or SiteAccess/ChangeBehaviors.py, if you minor glitchlet: it's in BaseRequest.py.
use SiteAccess), change the lines:
if user is None and roles != UNSPECIFIED_ROLES: response.unauthorized() to: if user is None and roles != UNSPECIFIED_ROLES: object = response.unauthorized
Under normal circumstances, this has no effect, since 'response.unauthorized' will be called as soon as it is returned and will raise its exception as usual. Now however, we add a twist; When the cookie-based authenticator fails, it replaces 'response.unauthorized' with its 'login' document. If no higher-level authentication succeeds, the 'login' document is rendered normally. Since 'response' is re-created with each request, this modification has no effect beyond the current request.
I'm trying to puzzle through the access control code - right now, if a login validate method fails, they typically do something like raise 'LoginRequired', self.docLogin(self, request) should they just, in this case, return back None, and let the machinery deal with it? Hm, in that case, wouldn't that then just recurse back through the parent folders looking for additional access controls? So if you had /a/acl_users and /a/b/acl_users, and both used something like the above, a request to /a/b/foo would get the /a/acl_users' docLogin page... ? Anthony
From: Anthony Baxter <anthony@interlink.com.au>
I'm trying to puzzle through the access control code - right now, if a login validate method fails, they typically do something like raise 'LoginRequired', self.docLogin(self, request)
should they just, in this case, return back None, and let the machinery deal with it?
After plugging self.docLogin into REQUEST, yes.
Hm, in that case, wouldn't that then just recurse back through the parent folders looking for additional access controls?
Exactly :-) This can allow authentication to succeed at a higher level, while still giving you the nice inner Login page if it fails at all levels. This isn't necessarily desirable in all cases, and you can't even *get* a basic authentication dialog when there's an inner cookie-based acl_users unless you define a method which explicitly throws 'LoginRequired'. It's still an improvement on the current default situation, though. Cheers, Evan @ 4-am
On Tue, 25 Jan 2000, Anthony Baxter wrote:
I'm trying to puzzle through the access control code - right now, if a login validate method fails, they typically do something like raise 'LoginRequired', self.docLogin(self, request)
should they just, in this case, return back None, and let the machinery deal with it? Hm, in that case, wouldn't that then just recurse back through
That would be correct.
the parent folders looking for additional access controls? So if you had /a/acl_users and /a/b/acl_users, and both used something like the above, a request to /a/b/foo would get the /a/acl_users' docLogin page... ?
Yes. I don't see a problem with this as long as its documented. It would be possible for /a/acl_users to see if the hook as already been modified, and not mess with it if that is the case. -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
participants (3)
-
Anthony Baxter -
Evan Simpson -
Stuart 'Zen' Bishop