[Zope-PAS] Cookie Auth Monopolizes Challenge?

[Sidnei da Silva]

On Fri, Aug 12, 2005 at 11:04:16AM +1000, Mark Hammond wrote:
|
<snip excellent explanation about why the protocol was introduced>
|
| It sounds like the problem is that PAS does not have any concept of the
| "source" of the request.  The existing behaviour seems correct (enough) for
| the standard case of a web browser hitting the site on a standard HTTP
| port - but not for the other ways to get at the site.

That is straight to the point. After pondering for a little while,
I've came to the conclusion that all 'clients' should, for sanity
sake, use the exact same set of plugins, except for IChallengePlugin.

And the reason is because IChallengePlugin seems to be the only one
that actively 'changes the environment' in a way that might affect the
'client application'. All the other plugins are 'passive' client-wise,
that is they can be completely ignorant about the kind of request or
client being used to talk to Zope.

| What *might* be possible is something like the following untested patch,
| adapted from what Chris posted:
| 
| --- PluggableAuthService.py     27 May 2005 19:10:45 -0000      1.31
| +++ PluggableAuthService.py     12 Aug 2005 01:00:58 -0000
| @@ -990,7 +990,13 @@
|          plugins = self._getOb('plugins')
|          challengers = plugins.listPlugins( IChallengePlugin )
| 
| -        protocol = None
| +        if self.isDAVRequest(request):
| +            # DAV clients/EE can't deal with form-based auth, so
| +            # we insist on the http protocol
| +            protocol = "http"
| +        else:
| +            # Other sources get anything that might be configured.
| +            protocol = None
| 
|          for challenger_id, challenger in challengers:
|              challenger_protocol = getattr(challenger, 'protocol',

That looks pretty much like what I had in mind, except I wouldn't
hardcode the default protocol to 'http'.

| However, I assume the same concerns exist even when the request comes via
| xmlrpc, ftp, etc.  I'm not sure what to do about those cases.

I would say each different request type might only be compatible with
a set of protocols. I would go even further and say it's not even a
task for the plugin or for PAS to decide what protocol each request
type should use, but it should be a task for the site administrator.

An example: While I can't think of a existing WebDAV client that can
authenticate using say NTLM (maybe Windows Folders?), that doesn't
mean one can't create a it's own custom WebDAV client that *does* do
NTLM authentication (*hint* *hint* Mark?).

So my proposal would be to special-case the IChallengePlugin and let
the site manager (or whatever title the person in charge of
configuring PAS has) select which set of 'protocols' is allowed for
each 'request type', where 'request type' would fall into 'browser,
xml-rpc, webdav, ftp' but could be extended to support new
request type. In fact, maybe this part could even be abstracted into a
'IRequestTypeSniffer' plugin.

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com