[Zope] Authentication/Validation & overriding exception responses patterns

[Andrew Athan]

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.