Background:
The pluggable authentication utility (hereafter called PAU; found in
zope.app.authentication) allows two kinds of plugins, credential
plugins and authenticator plugins. The PAU currently keeps track of
the names that it should use for these two types of plugins, and then
looks up utility components by those names. The plugin utilities
know of no relation to the PAU, and there is nothing stopping a
single utility from being used for multiple PAUs.
Principals from authentication utility plugins have ids that are
comprised of three components: the PAU prefix, the authentication
plugin utility prefix that identified the user, and the
identification of the user within the authentication plugin.
Primary Problem:
Some plugins want to know what PAU they are associated with. They
also may only want to be used by a single PAU.
For instance, if a authenticator plugin wishes to convert some of its
local principal information into a principal or principal id, perhaps
to fire an event, it cannot: the PAU is the only component that knows
how to do that, in part because of the composition of ids described
in the second paragraph of background, above.
Another example is that groups folders should only be applied to
principals defined in its same PAU: principals defined in sites above
will never have a chance to ask the lower groups for their blessing
(see zope/app/authentication/groupfolder,txt, the "Limitation"
section at the bottom). Group folders cannot maintain that
constraint themselves, because
Secondary Problem:
It would be nice to not have to do the utility registration dance for
local PAU plugins.
Tertiary Problem:
The PAU is a site management folder, which means it can hold local
utilities; it typically is used to hold plugin utilities, and this is
a bit misleading. Adding them in the PAU does not do anything unless
you register them as a local utility; and there's no difference in
doing that in the PAU or in a normal site management folder. The
registered plugins can in fact be used by PAUs below the one in which
they reside, which is again not obvious.
Consideration:
Some (many?) plugins *are* appropriate to be shared--credentials
plugins are often sharable, for instance. The utility pattern does
have merit, and should be maintained.
Solution:
In addition to utility-based plugins, allow contained plugins, which
are looked up by name from within the PAU.
Adding a plugin to the PAU would immediately make it available to be
used by the PAU, without having to register it as a utility. The id
in the container would be the name for the lookup. Container names
would mask utility names (i.e., the container names would have
precedence).
Some plugins would want to only be contained item plugins, some would
want to only be utilities, and others might be flexible, supporting
use as contained items or registered utilities.
Contained item plugins could count on __parent__ being the relevant
PAU; if their __name__ was one of the configured plugins in the PAU,
then they are active. The PAU's prefix adds the missing link to get
a full principal id, and the PAU API adds the missing link to get a
principal.
PAU UI might not have to change too much, though it would help the
tertiary problem if utility plugins and contained item plugins were
clearly distinguished in the PAU container UI.
The Group Folder would become a contained item plugin. Others might
follow.
Notes:
This is reminiscent of the Zope 2 PAS approach.
Risks:
Some additional complexity, perhaps.
Thoughts appreciated.
Gary
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
