Jim Fulton wrote:
> When I did the initial design for the pluggable-authentication utility
> (PAU), I came up with a strategy for managing principal ids, in
> retrospect, is overly complicated. This suspicion is supported by the
> fact that I originally got the implementation of this wrong.
> An authenticator plugin, among other things, manages principal ids.
> Principal ids need to be unique system wide. In a misguided attempt to
> make life easier for plugin authors, I decided that that the PAU should
> have a prefix that it adds to principal ids.
> This means that plugins that manage principal ids can't get at principal
> ids without accessing their PAU, which further means that a plugin can
> only be used with a single PAU.
> I'd like to get rid of the PAU prefix and simply require that
> authenticator plugins provide system-wide unique ids. This can be done
> by providing suitable prefixes on each plugin.
> I suggest that, for 3.4, we get rid of the PAU prefix option and provide
> a generation evolution script that, for PAUs with non-empty prefixes,
> just prepends their prefixes to their plugin prefixes and clears their
So I imagine that when I add an authenticator plugin to a PAU, I'll have
to specify a fully qualified prefix, not just its prefix within the PAU.
> I'm sorely tempted to do this for 3.3.
No more surprises for Zope 3.3, please. Zope 3.4 is only 3 months away.
For all I care, the only feature it can have is to get rid of the PAU
annoyance... But Zope 3.3 needs to stay frozen. We'd be making fools of
ourselves (if we aren't doing that already) otherwise.
Zope3-dev mailing list