Shane Hathaway wrote:
> Steve Alexander wrote:
>> In Launchpad, request.principal is not used by the application
>> programmers. It is used only by the authentication, authorization and
>> publication machinery. The machinery looks up a Person (an application
>> domain object) for the current principal (the participant, if you will)
>> and makes this available to application code. So, application code
>> deals with an application-level object, not some security system
> It sounds like you're saying only the security machinery should know
> about principals, and that everything else deals with users. If so, it
> should not be necessary for any Zope 3 developer to learn about
> principals unless they are writing security machinery. Is that right?
You need to know about principals if you are writing security machinery,
or if you are writing the thing that maps principals to whatever passes
for "users" in your application.
What typically happens is, the request contains credentials. The
principal represents the fact that those credentials have been checked
and found to be ones that the system knows about. It also represents
the type of credentials, for example, how much you trust them. This in
turn maps to the concept of "a user accessing your system".
credential -> principal -> user
The Zope 3 framework can take care of the credentials and principals.
The users are application-specific. A content management system for
Zope 3 would have its own concept of what a user is, but still use the
Zope 3 concepts and implementations of principal and credential. A room
booking and timetabling system may have a different concept of a user,
as a user may well be a specific instance of a content object such as a
person (who is a bookable resource).
Zope3-dev mailing list