[Zope3-Users] Authentication, Principals and PAU...

[Gary Poster]

On Feb 13, 2006, at 6:17 PM, luis wrote:

>
> hi all,
>
> I'm trying to get started with zope3, and while I think I'm  
> beginning to
> understand parts of it, I'm still having a hard time with other  
> parts, so I
> hope someone here can help me out a bit.
>
> my first questions are concerning authentication/ users / pau...
>
> as a learning-excercise i want to create an example app, where  
> users can
> register themselves, login and upload files.
>
> I added one PAU to my site which uses session credentials and a
> principalfolder.. so now I can create users in that folder and can  
> log into
> the system. that works, but when I tried to add additional information
> (mail, etc) using the principal annotation utility, it just doesnt  
> work...

There are many ways to add annotations for a user.  If you already  
have a principal object, and your zcml has included the  
principalannotation package (as I expect Zope 3 does by default),  
then you can just say

from zope.app.annotation.interfaces import IAnnotations
annotations = IAnnotations(principal)
annotations['my.package.name'] = 'whatever' # or a btree or whatever

Lots of other ways to do it, but that's one.

> I created the interface and class to store the data, and tried to  
> register
> them with a zmcl adapter and browser:editform
> for="zope.security.interfaces.IPrincipal", but nothing happened...  
> so far
> I've been able to trace it down, the objects in the principalfolder  
> do not
> implement IPrincipal, but only IInternalPrincipal, so my "mapping"  
> in zcml
> is not active for my users.

I'm not clear what you want to do here.

>
> to be honest, the difference between principals, internalprincipals  
> and
> principalinfos is not that clear to me.

IPrincipals are the primary security interface for principals.  The  
others I expect (without bothering to look at the code) are  
implementation specific for a given authentication utility.  With the  
pau, principals  objects are generated as needed, on the fly, and not  
persisted themselves.

> I then downloaded schooltool to have a look how they implemented users
> there, and they don't use the pau at all, but created an own  
> authentication
> utility. and they don't use the principal annotation util either,  
> but store
> the person details as annotations on the objects themsleves..

That's one of the wonders of Zope 3: don't want to use implementation  
X of interface A?  Write your own implementation Y for interface A  
and register it instead.  As long as it complies with the interface,  
the intent, and the reality whenever I've tried it, is that you  
should be good to go.

I don't know schooltool's history.  There could be many reasons for  
them rolling their own.

> ...so...is this the recomented way of doing things? is the pau only  
> meant to
> be an example auth-utility and applications are supposed to  
> implement their
> own auth. mechanism? or maybe use the pau as a basic framework, but
> implement your own "principalfolder" as a pau-plugin?

The pau is a basic framework, with a number of reasonable basic  
implementations.  Plugins, such as the LDAP plugin in the  
svn.zope.org repository, can add capabilities to the pau.

> something else i noticed, is that in the pau the principalfolder lives
> "inside" the pau itself (the pau acts as a container) in software  
> space
> (++etc++site), while in schooltool the users live in the "persons"  
> folder
> in content space.
> is there a difference between software and content space for this?,
> specially in regard to users being able to register on their own,
> user-search or something else that can only be done in content- 
> space but
> not in software/configuration-space or viceversa?

It's a design decision.  We have provided views in content space that  
manipulated objects actually over in ++etc++site.  Also, since many  
pau plugins are utilities, when Jim's 'put utilities anywhere'  
proposal comes in you could in theory do precisely what schooltool  
did with a principals folder in content space but the auth utility  
still in ++etc++

Gary