Authentication/Validation & overriding exception responses patterns
Root acl_users --YourFolder --acl_users(e.g., LoginManager) So it seems to me that Zope's user validation mechanism has a "feature" ("flaw"): There is no way to unequivocally deny access or completely change the login behavior for a resource from within YourFolder's acl_users other than to raise an exception. This is because returning 'None' from within your validate method causes Zope to seek validation up the path. At best, such as when Zope's "standard" mechanism of user acquisition is what's desired here's what will happen: If there is user data in the cookie, and that user exists & is valid, the request will be validated by the higher level folder and the higher level folder's user's roles apply. That's standard Zope behavior, right? Acquisition If the cookie does not contain a validated user, the higher level folder will attempt authentication. This will be the ugly browser panel. If you DON'T return None then Zope assumes the request has been validated with that user. This is not the desired behavior either. Even staying out of the realm of python/product code, if you restrict the permissions of an object severly in YourFolder, and your acl_users folder wants to deny access based on these restricted permissions, what can it do? If it returns None, the user will get re-authenticated higher up. If it returns a user, the page will be displayed. I have nothing against exceptions per-se, except that they seem to circumvent the "natural" progression of events within the Zope server. E.g., transactions and other request/response handling gets co-opted. Aren't there situations where it would be valid to engage in certain server side interactions --even though-- the requested page was forbidden or the user unknown? So, if raising an exception is simply the accepted means of handling this type of situation, then I have a few more questions: (1) What is the accepted pattern for overidding HTTPResponse's exception() code? I see that the original LoginManager code swizzles the unauthorize() function pointer, is that what I should do to change exception handling too? (2) How do people typically make sure that "pretty" exception pages are displayed to users? Is the accepted paradigm to put a <dtml-try> wrapper in the standard-html_header/standard-html_footer? Thanks in advance, A.
Hi Andrew,
So it seems to me that Zope's user validation mechanism has a "feature" ("flaw"): There is no way to unequivocally deny access or completely change the login behavior for a resource from within YourFolder's acl_users other than to raise an exception. This is because returning 'None' from within your validate method causes Zope to seek validation up the path.
This is about right.
At best, such as when Zope's "standard" mechanism of user acquisition is what's desired here's what will happen: If there is user data in the cookie, and that user exists & is valid, the request will be validated by the higher level folder and the higher level folder's user's roles apply. That's standard Zope behavior, right? Acquisition
The user folders are not found via acquisition, but that's a good description.
I have nothing against exceptions per-se, except that they seem to circumvent the "natural" progression of events within the Zope server. E.g., transactions and other request/response handling gets co-opted. Aren't there situations where it would be valid to engage in certain server side interactions --even though-- the requested page was forbidden or the user unknown?
Yes, probably. In practice, though, the interaction is at such an early stage in the request that throwing an exception doesn't usually coopt any important transaction data. Do you have a need to not throw the exception due to a requirement to write to the ZODB before successful auth?
So, if raising an exception is simply the accepted means of handling this type of situation, then I have a few more questions: (1) What is the accepted pattern for overidding HTTPResponse's exception() code? I see that the original LoginManager code swizzles the unauthorize() function pointer, is that what I should do to change exception handling too? (2) How do people typically make sure that "pretty" exception pages are displayed to users? Is the accepted paradigm to put a <dtml-try> wrapper in the standard-html_header/standard-html_footer?
1. I don't know. ;-) 2. Yes. HTH, - C
your validate method causes Zope to seek validation up the path.
This is about right.
That's standard Zope behavior, right? Acquisition
The user folders are not found via acquisition, but that's a good description.
Right, I should have put that in quotes. I just meant it was a similar mechanism, heading up the path.
Aren't there situations where it would be valid to engage in certain server side interactions --even though-- the requested page was forbidden or the user unknown?
Yes, probably. In practice, though, the interaction is at such an early stage in the request that throwing an exception doesn't usually coopt any important transaction data. Do you have a need to not throw the exception due to a requirement to write to the ZODB before successful auth?
I actually have no such need right now other than the fact that I've been fighting with LoginManager trying to make it behave reasonably. As I looked at the Zope source I was thinking of ways to improve on it.
type of situation, then I have a few more questions: (1) What is the accepted pattern for overidding HTTPResponse's exception() code? I see that the original LoginManager code swizzles the unauthorize() function pointer, is that what I should do to change exception handling too?
1. I don't know. ;-)
Looks like zhttp_exception_hook (or whatever it's called, can't remember now) looks for a property called raise_standardErrorMessage starting at the published object and then up the path. (Zope/__init__.py)
(2) How do people typically make sure that "pretty" exception pages are displayed to users? Is the accepted paradigm to put a <dtml-try> wrapper in the standard-html_header/standard-html_footer?
2. Yes.
Having now found raise_standardErrorMessage, I'll have to investigate why using it isn't a "better" way...
Chris McDonough wrote:
is that what I should do to change exception handling too? (2) How do people typically make sure that "pretty" exception pages are displayed to users? Is the accepted paradigm to put a <dtml-try> wrapper in the standard-html_header/standard-html_footer?
2. Yes.
Really? I thought you just did something useful in standard_error_message. Now if only that was used in authentication errors.... cheers, Chris
Actually, excuse me, I didn't read it properly... I meant it was common practice to massage standard_error_message... not standard_html_header or standard_html_footer But since you bring up the point that authentication errors aren't handled this way, this doesn't help much. ;-) I need to read the code to see what happens. :-( ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Chris McDonough" <chrism@digicool.com> Cc: <aathan-zope-list@memeplex.com>; <zope@zope.org> Sent: Thursday, April 12, 2001 11:19 AM Subject: Re: [Zope] Authentication/Validation & overriding exception responses patterns
Chris McDonough wrote:
is that what I should do to change exception handling too? (2) How do people typically make sure that "pretty" exception pages are displayed
to
users? Is the accepted paradigm to put a <dtml-try> wrapper in the standard-html_header/standard-html_footer?
2. Yes.
Really?
I thought you just did something useful in standard_error_message. Now if only that was used in authentication errors....
cheers,
Chris
participants (3)
-
Andrew Athan -
Chris McDonough -
Chris Withers