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.
Looking at the current state of the patch , 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
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.
> 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
>> — 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
>> tell you about the details here...
> I still see no reason this can't be done in a plugin, as long as you
> 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 —
>> 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.