[Zope-dev] Re: [Plone-developers] PAULA: bringing Zope 3's
authentication to Plone and beyond
Florian Friesdorf
flo at chaoflow.net
Mon Jul 21 05:56:38 EDT 2008
On Fri, Jul 18, 2008 at 05:00:50PM +0200, Hermann Himmelbauer wrote:
> Am Freitag, 18. Juli 2008 03:55 schrieb Florian Friesdorf:
> (..)
> > In case you store your userdata in RDB, you do not need InternalPrincipal
> > at all. I currently see to options:
> >
> > 1. custom AuthenticatorPlugin, AuthenticatedPrincipalFactory and
> > FoundPrincipalFactory from principalfolder.py. Your AuthenticatorPlugin
> > would need to return PrincipalInfo objects. Further, you write an event
> > handler that listens for FoundPrincipalCreated and
> > AuthenticatedPrincipalCreated, which puts all needed/wanted properties onto
> > the Principal object, which was created by one of the factories. Those
> > properties can be real python properties with get,set,del methods, which you
> > can use to get,set,del the actual propety values wherever they may come
> > from, e.g. an RDB.
>
> Hmmm, interesting approach. But would that also mean that the principal may
> hold also sensitive information, e.g. the password? Are there any security
> concerns about doing so?
You won't need it for authentication, so it would be sufficient to support
setting the password through the principal object, which then would
transparently work on the RDB.
> > > Sure it's possible, that's what I did. But it was quite complicated and I
> > > had to dig very deep into Zope3 code to do that. This is definitely no
> > > option for a Zope developer who needs to quickly set up a cookie-less
> > > application.
> >
> > Did you make your cookie-less credentials plugin available somewhere?
>
> I can send you my code, if you like. However, it's somehow a little bit ugly
> due to some Zope3 internals I could not understand/solve.
Would be nice to have it, though I don't know whether I'll have the time for a
closer look and eventually help you with Z3 stuff, at least until Aug 18th (end
of GSOC).
> What I moreover think about is why not to pull the PAU stuff out of zope.app
> and create a package such as "zope.authentication". This may be more generic.
I think most of the code assumes running inside the zope application server
using ZODB (Persistent), so it won't be useful outside.
> To sum it up, during authentication, user information is needed four times:
>
> 1) In customization of authplugin.authenticateCredentials (to check for
> correct login/pass)
> 2) In the Authenticated PrincipalFactory, or, better, in a subscriber to that
> event which stuffs out the principal with all needed data
> 3) For getPrincipal() calls (Two in my case for every request, no clue why and
> where they are called).
>
> In case of a not-so-fast access to user data (such as in my case, where RDB
> queries have to be issued), caching can heavily improve the performance.
>
> So, it seems, a good idea would be to create some caching-related package that
> integrates nicely with the PAU.
I am not sure, whether this can be generalized or should be specific to where
the data is coming from.
> Yes, many thanks to you, too. And I would also be very interested in hearing
> comments about this from others.
It seems there aren't too many people using PAU...
> BTW. I also send this to Roger Ineichen, as he also suffered from shortcomings
> of zope.app.authentication and built his own "z3c.authentication", which is
> also an interesting read. (Although I could not yet find time to play around
> with it).
Interesting, will have a look.
florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080721/f1d41887/attachment.bin
More information about the Zope-Dev
mailing list