Roger Ineichen wrote: > pluggableauthentication utility > > > Hi Jim, > > perhaps we can discuss this on zope3-dev. > > From: Jim Fulton [mailto:[EMAIL PROTECTED] >> Sent: Thursday, June 16, 2005 12:03 PM >> To: [EMAIL PROTECTED] >> Cc: 'GMane'; firstname.lastname@example.org >> Subject: Re: [Zope3-Users] pluggable authentication utility >> >> Roger Ineichen wrote: >>> Hi Ricki >>> >>> On Behalf Of GMane >>> >>>> Sent: Wednesday, June 15, 2005 5:52 PM >>>> To: email@example.com >>>> Subject: [Zope3-Users] pluggable authentication utility >>>> >>>> Hi, >>>> I have a simple question about pluggable authentication. >>>> >>>> I created a folder and I made it a site. >>>> In the default Site-Management Folder I created a Pluggable >>>> Authentication Utility (named plaut). >>>> Inside it I made a PrincipalFolder (Partner) and added a user soc1. >>> >>> >>> Don't give a name (plau). Pluggable authentication utilities >>> are as dfault unnamed. All components right now will lookup the >>> PAU with name=''. >> >> For 3.2, we need to find a way to make this clearer. Either we need >> to provide a more verbose description of what the name is for or >> perhaps, as Stephan has suggested, for components that are always >> looked up without names, we should not provide the option of >> entering a name and, for others, we should require a name. > > We have to totaly hide this part and offer a different concept. > Of corse the normal registration will be available too. > > I propose to add something like a policy. A policy should register > a utility. This means we can add policies via ZCML and the user can > only process this policy which registers the utility in a predefind > way. > > Then we can provide a task like. "register PAU" and everything gets > registred. There could also be a different policy like: > "register PAU with initial principal folder" etc. > > A ZCML directive could look like: > > <utilityPolicy > name="Add PAU with principal Folder" > for=".interfaces.IPluggableAuthentication" > class=".authentication.AddPAUWithPrincipalFolderPolicy" > /> > > Then we can offer adding utilities via this policies. > > If somebody likes to register a utility in a different way, he can > add own policies for a utility. > > I use this pattern in a own registry in a different usecase. It makes > it very simple for anduser and even me to register components in a > registry. And you don't have to know every little about the > registration process. > > What do yo think about that? Any other ideas?
It looks like you've identified a common enough use case: PAUs are typically used with a common set of plugins. The current PAU design accommodates all sorts of use cases that most users would never face. Rather than add more complexity to the registration process with "utilityPolicy" (even though it's an attempt to make things easier for the user), I'd suggest creating a SimplePluggubleAuthenticationUtility that supported the most common use cases. Something like this perhaps: class ISimplePAU(Interface): authentication = Choice(values=('HTTP-Auth', 'Session')) allowUserChangeOnUnauthorized = Bool() principals = Attribute("A PrincipalsFolder plugin.") This would be far easier to deal with than the current PAU for those that don't need PAU's flexibility. -- Garrett _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com