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

Zope3-users mailing list

Reply via email to