[Twisted-Python] mind, twisted.cred and HTTPAuthSessionWrapper

[Esteve Fernandez]

On Thursday 19 February 2009 19:46:59 Jean-Paul Calderone wrote:
> >But, in our case, requestAvatar can only return something based on what
> > the checker returns. I mean, requestAvatar receives an avatarId (as a
> > result of Checker#requestAvatarId), a mind and a bunch of interfaces, but
> > the realm doesn't have any other information.
> >
> >What our checker does to authenticate an user, is to call a method on a
> > remote service and get back an object (a token) that represents the state
> > of a conversation between a client and that remote service. Then, the
> > client may issue more remote calls using the previously received token.
> >
> >We're using Twisted.web only as a front end to a remote service, and we'd
> > like to make it as decoupled as possible, as there will be other
> > frontends.
>
> What if you use the token as the avatarId?

But the general contract for requestAvatarId is to return a string identifying 
the user. From ICredentialsChecker#requestAvatarId documentation:

"Returns - a Deferred which will fire a string which identifies an avatar, an 
empty tuple to specify an authenticated anonymous user (provided as 
checkers.ANONYMOUS) or fire a Failure(UnauthorizedLogin). Alternatively, 
return the result itself."

If so, our problem is that the token is an object that contains more 
information (a timestamp, a cryptographic signature, etc.), so serializing 
and deserializing it everytime we need that information is a bit cumbersome. 
The remote service checks that token everytime it receives a call, and 
responds with an appropiate response.

> >I tried to mimic PB's behaviour, in the sense that (as the cred
> > documentation puts out):
> >
> >"it is an object which serves an important role - any notifications which
> > are to be relayed to an authenticated client are passed through a 'mind'.
> > In addition, it allows passing more information to the realm during login
> > in addition to the avatar ID."
>
> This is technically true but as far as I know no one has ever actually used
> it that way.  I'm trying to think of an authentication scheme which would
> benefit from it (let alone require it), but I'm drawing a blank.  PB just
> has enough expressive power already to really need this.

In that case, (although we might not actually need a mind in the end), would 
PB have the same problem with HTTPAuthSessionWrapper? The mind argument is 
always None (in HTTPAuthSessionWrapper#_login):

    def _login(self, credentials):
        d = self._portal.login(credentials, None, IResource)
        d.addCallbacks(self._loginSucceeded, self._loginFailed)
        return d

So, I think HTTPAuthSessionWrapper should have a method (e.g. 
createMind(self)), which would return None by default and that could be 
overridden by subclasses if they need to return something else. I'll gladly 
file an issue, provide a patch and a test case, if you think it's a valid 
issue.

> No problem.  Hope this has helped in some way, at least.

Thanks!