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!
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
