On Thu, 19 Feb 2009 20:22:30 +0100, Esteve Fernandez <est...@sindominio.net>
wrote:
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.
The convention is for avatarId to be a string, but as the anonymous case
indicates, that's not strictly required. :) The real requirement is that
the realm be able to interpret the avatarId. The way this generally works
is by making it a username string, but you're in charge of the realm, so it
can be whatever you like. Of course, this makes it harder to re-use either
your checker or your realm with different components, but sometimes that's
okay. It might be nice if this were explained in some document somewhere
but I don't think the current cred document should cover it, since going
into complex and subtle points like this tends to make it harder to get
the basic idea. An advanced cred howto of some sort might be merited.
>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):
I'm not quite sure what you mean here - how should I equate PB and
HTTPAuthSessionWrapper?
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.
It probably *is* a good idea to allow the mind to be created somehow. It
was only omitted because no obvious use-cases presented themselves at the
time. I'm still not really convinced that this use case is a good one
though, so I'm not sure I'd be in favor of adding the hook now in order
to support this. ;)
In general, the mind feature of cred is underutilized, underdocumented,
and poorly understood. Fixing these problems is great, but it may also
be the case that the mind is such an obscure use-case that most people
really just don't care about it.
Jean-Paul
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
