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
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
