[Zope3-dev] proposal: allow contained PAU plugins

Gary Poster gary at zope.com
Fri Jan 13 21:58:21 EST 2006


On Jan 13, 2006, at 6:34 PM, Roger Ineichen wrote:

> Hi Gary

Hey Roger

>
> [...]
>
> All arguments are Ok for me.

Cool.

> But I think the PAU at all is to complex
> and this whoul not change.
>
> Do we really need such a complex authentication module in z3?

Well, I know it has come in handy for us.  Also, though YMMV, I find  
it actually much simpler to understand than the Zope 2 PAS--which was  
also developed because ZC needed the flexibility.  Jim, and then  
Garrett, I understand, have tried to make the Z3 PAU as streamlined  
as possible.

> What does this mean to the queriable sources and their API?

I assume you mean, what does my proposed change mean there.  Not  
much, as far as I can tell.  The getQueriables method on the  
authentication utility would use the new approach to get the  
authenticator plugins, but nothing much would change for the  
queriables (unless a queriable *wanted* to act differently when it  
got a plugin found via containment, I suppose).

> A long time ago I was improving the grant form in z3 and implemented
> a grant vocabulary based on queriable sources. All I can say
> about that part is, it's too complex and hard to develope with.

Yes, we didn't bother with the PAU queriable source pattern but did a  
much simpler, less flexible, but more practical one still using the  
PAU data.  There might not be a good one-size-fits-all approach to  
the problem.

>> Risks:
>> Some additional complexity, perhaps.
>
> I'm sure we will get additional complexity.
>
> But I can live with that. The only question is, should the PAU
> be a component where other people can use as a base and develope
> additional concepts like different UI or is, the PAU is only a
> core component where only should be used for register custom
> developed plugins.
>
> I guess the real problem is, that the PAU supports only
> modularity for register own plugins all other parts are
> implemented as none replacable component and you need some
> functionality whcih is not implemented right now.

Two replies to this.

First, in this particular case, the problem was that the PAU design  
had called YAGNI on this kind of use case, and now I do need it.  It  
was a PAU design problem, and I don't think that it's necessarily an  
example of the need for more modularity.

Second, you might be right anyway that we need more modularity and  
flexibility; however, I still hold out hope that the design is  
sufficient, or can be with relatively minor refactoring.  The  
combination of credential plugins, authentication plugins, a  
malleable principal object, and events and subscribers is pretty  
powerful; ordered subscribers might be needed eventually, but that's  
an older and broader topic with old discussion.

Also, making the PAU more modular will make it more complex, which  
was your first concern in the email.  There's definitely a tension  
between flexibility and complexity, and it's worth trying to see what  
we keep simple.

> I'm a little afraid that this is not the only refactoring
> in the next future if we not support more modularity in PAU.

You might be right that the PAU will in for a bigger refactoring in  
the future.  For now, I'm happy with trying to tackle it in smaller  
chunks.

Thanks for your thoughts

Gary


More information about the Zope3-dev mailing list