On Feb 13, 2006, at 6:17 PM, luis wrote:
I'm trying to get started with zope3, and while I think I'm
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
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
the system. that works, but when I tried to add additional information
(mail, etc) using the principal annotation utility, it just doesnt
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
them with a zmcl adapter and browser:editform
for="zope.security.interfaces.IPrincipal", but nothing happened...
I've been able to trace it down, the objects in the principalfolder
implement IPrincipal, but only IInternalPrincipal, so my "mapping"
is not active for my users.
I'm not clear what you want to do here.
to be honest, the difference between principals, internalprincipals
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
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
utility. and they don't use the principal annotation util either,
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
be an example auth-utility and applications are supposed to
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
(++etc++site), while in schooltool the users live in the "persons"
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-
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