[Twisted-web] Sessions and Authentication for Web2

[Phil Mayers]

Jean-Paul Calderone wrote:
> On Tue, 29 Nov 2005 17:26:32 +0000, Phil Mayers 
> <p.mayers at imperial.ac.uk> wrote:
>>
>> [snip]
>>
>> class MultiPortal(Portal):
>>   def login(self, credlist):
>>     for c in self.checkers:
>>       # All or a subset...
>>       if c.canHandle(credlist):
>>         return c.login(credlist)
>>     for c in self.checkers:
>>       c.maybeChallenge(credlist)
>>
>> ...which starts to look very different from cred as-is
> 
> I haven't had time to catch up on this thread, but I wanted to point out 
> that it is pretty much always wrong to subclass Portal.  If you ever 

Yes, wanting to is a symptom of the underlying problem, which is that 
for HTTP and Digest auth, you have to send the initial challenge back 
with the 401. To do this, you have to communicate with the checker to 
generate said challenge, or implement the digest algo. inside the HTTP 
proto, which is way nasty and breaks sharing. This either means:

  * "just deciding" that the client *will* use digest, creating a digest 
creds object that will issue the 401 and challenge, and calling "login" 
with it - losing auth mechanism negotiation support, which is nasty

  * holding a reference to a "challenge" method on the digest checker, 
and potentially any other challenge-with-401 mechs, breaking the 
encapsulation, which is nasty

  * adding a pre-login-stage mechanism to portal, or otherwise futzing 
the API, which is nasty

I would add that the listCredentialInterfaces method is not really 
sufficient for a completely configuration-free decision on what 
mechanisms to present the client - some (e.g. plain/login) may only be 
available over certain channels depending on policy, and deciding that 
policy may require a method call into the checker *instance* with a 
protocol-neutral description of the "connection characteristics" (e.g. 
the SSF in SASL)

It is, in general, a non-trivial problem in any environment. None of 
these issues are specific to Twisted. Witness the hassle GSSAPI, SASL 
and EAP cause. But to drag this back on topic, the original discussion 
was that t.web2 was MANDATED to use t.cred for authentication, and it 
seems to me at least there are unanswered questions about how it will work.

I'm sure it will, and am interested in working out how - hence the 
flurry of emails. Perhaps I'll have another go next week (since I am 
moving datacentre for the rest of this one)