[Zope-PAS] [Collective-checkins] r93341 - in mr.ripley/trunk: . src/mr/ripley

[Stefan H. Holek]

Hi All,

Short version:
PAS cannot be entirely ignorant of masquerading, because plugins are  
allowed to call back to "their" PAS (via _getPAS()) and may pass login  
names containing masquerading information.

Long version:
Looking at the current state of the patch [1], the part titled "Line  
599" would go into _extractUserIds(). I agree that in theory this part  
could be implemented as a plugin. A complex to write and to administer  
plugin to be sure, but a plugin nonetheless.

The part titled "Line 813" however, goes into _verifyUser() for the  
reason stated in the intro. Thing is, there are plugins out there that  
make use of the callback privilege, like, incidentally, the  
plone.session plugin, which calls _verifyUser() passing a decorated  
login name. Note that the plugin cannot avoid using the decorated name  
without becoming aware of masquerading itself. Now here comes the  
headache.

Putting masquerading into PAS directly would allow all plugins (and  
their writers) to stay ignorant of the feature. It would furthermore  
keep configuration requirements to a minimum, which is always a plus  
in my book.

Cheers,
Stefan

[1] <http://svn.zope.org/Products.PluggableAuthService/branches/shh-15-masquerading/Products/PluggableAuthService/PluggableAuthService.py?r1=text&tr1=97358&r2=text&tr2=97553&diff_format=h 
 >



On 03.08.2009, at 13:52, Wichert Akkerman wrote:

> On 8/3/09 13:45 , Andreas Zeidler wrote:
>> stefan of course already told me about you being somewhat reluctant
>> regarding the patch, but since he's refactored it again in the  
>> meantime
>> — resulting in a much smaller patch set[*] — i'd really like you to
>> review it again and perhaps reconsider. afaik it's still not quite
>> possible to do this exclusively in a plugin, but perhaps stefan  
>> should
>> tell you about the details here...
>
> I still see no reason this can't be done in a plugin, as long as you  
> get
> the plugin ordering correctly. Until you can convince us that this
> really can't be a plugin the patch should not go in.
>
>> in any case, the functionality is very useful in a lot of cases —  
>> most
>> obviously for people doing support, but also for testing deployments
>> like in this case.
>
> I have no problem with the implementation, just the fact that this is
> not implemented as a normal plugin.
>
> Wichert.


--
Stefan H. Holek
stefan at epy.co.at