[Zope-dev] REQUEST.AUTHENTICATED_USER question

[vio]

Since customizing Zope's login process seems to be so painful, an alternative
would be to simply by-pass it: declare all the classes in my product who need
authentication as 'Public', then implement my own security scheme over those
classes ... which basically mirrors Zope's security, if not in the coding, 
at least in the principles and philosophy.
I know, adding another security layer who basically does the same thing is not 
the most efficient solution, and it is more risky (bugs and security holes), 
but at least it does the job according to my own specifications.

So guys, maybe consider making Zope's login process more customizable
in a future release, so other programmers concerned with this aspect of Zope
won't have to labor over understanding complex source code (Zope or 3d party), 
but can focus instead on more value-add tasks.

Best Regards,
Vio

* R. David Murray <bitz@bitdance.com> [020123 12:15]:
> On Mon, 21 Jan 2002, vio wrote:
> > called with REQUEST.RESPONSE.unauthorised(). It just happens that I really
> > don't like that 'Basic Authentication' dialog, that's why I want to use mine.
> 
> 
> > Which to me seems like a lot of overhead. If someone could point me to where
> > Zope keeps user state (I believe with a cookie on the user's browser,
> > but where in the source does Zope set this cookie up?),
> > I could simply re-write that cookie with the new User ID ... Just a
> > thought of a simple and elegant solution (aka 'magic bullet') for my problem.
> 
> Zope does not keep a user state anywhere.  For Basic Auth, the
> browser provides the credentials on each transaction.  Cookie
> crumbler of course uses a cookie, which again is provided with each
> transaction by the browser.
> 
> Maybe what you should do is look at the exUserFolder product and
> write your own login methods (and possibly a User Source) against
> that.
> 
> --RDM