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...