Am Samstag, 12. Juli 2008 03:04 schrieb Florian Friesdorf:
> On Thu, Jul 10, 2008 at 10:56:19PM +0200, Wichert Akkerman wrote:
> > Previously Florian Friesdorf wrote:
> > > Hi *,
> > PAS works fine and covers a lot more functionality than PAU and there are
> > more PAS plugins than PAU plugins.
> PAU is doing things different than PlonePAS/PAS, but I don't see how the
> current functionality of PlonePAS/PAS could not be achieved with PAU?
At first, I very much appreciate putting working into PAU. I personally use
Zope3 only, so I have little experience with Zope2 and none with PAS,
therefore I can't compare them.
In my projects, I use PAU only, so I do have some experience with it. And my
personal impression is, that PAU is a very interesting approach, but it has
it's drawbacks. I would denote the following:
1) No way to pass PAU-related information to form-code: In PAU, the
authentication is entirely done before user code, e.g. form handling etc. In
my scenario, I have a login form (z3c.form based), which has two input fields
that comply to z3c.form, so if the correct user data is inserted in these
fields, I'm logged in.
If login data is wrong, then the form has no way to find out, why the login
process failed (e.g. "no such user", "wrong password", "no cookie support").
Moreover, my login form has a "Cancel" button, which should cancel the login
process. If correct login data is entered, and "Cancel" is pressed, the user
is logged in nevertheless.
2) Lack of documentation: The entities "Principal, InternalPrincipal,
PrincipalInfo" are very confusing to a newbie, I still don't get the "big
3) Lack of plugins: No plugin for URL-rewriting, e.g. cookie-less browsers
(retrieving auth-information from URL) etc.
I personally needed to write an authentication plugin for a SQLAlchemy based
RDB, and was confused a lot of how/why to create Principal / PrincipalInfo
objects: Should I create my own Principal/PrincipalInfo objects in order to
stuff information into them that my application needs? How excactly should I
cache user data so that a single browser request does not lead to multiple
RDB queries? And where in the big picture is the "User" entity? (It's
probably the InternalPrincipal object, I assume)...
PAU-based authentication now works for me to some degree, but it was a massive
fight, and for my case, it seemed that the PAU flexibility simply led to
complexity but was not flexible/thought out enough to support my specific,
but relatively simple scenario.
So I would very, very much suggest to dig into PAU first and fix those
shortcomings before porting it to Plone/Zope2.
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -