[Zope] Authentication/Validation & overriding exception responses patterns

[Andrew Athan]

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