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

[Jean-Paul Calderone]

On Thu, 19 Feb 2009 19:39:48 +0100, Esteve Fernandez <esteve at sindominio.net> wrote:
>On Thursday 19 February 2009 18:57:29 Jean-Paul Calderone wrote:
>> On Thu, 19 Feb 2009 18:47:37 +0100, Esteve Fernandez <esteve at sindominio.net>
>wrote:
>> >On Thursday 19 February 2009 18:28:59 Jean-Paul Calderone wrote:
>> >> What kind of "extra information" are you trying to pass?  Generally, all
>> >> information belongs with the avatar object.  The mind should be used to
>> >> interact with the protocol's notion of the user (as the avatar is used
>> >> to interact with the realm's notion of the user).
>> >
>> >Our checker generates a session per successful login, and all subsequent
>> > calls use that session to authenticate requests. The way I thought for
>> > using a mind is to create an empty object and populate it with the remote
>> > session object once the user has logged in successfully.
>> >
>> >Is a mind the right place to put that session?
>>
>> It doesn't seem like a good use of the mind to me.  I'd put the session
>> inside the avatar.  You may need a wider interface than IResource for
>> this, if you want to inspect the session from anywhere other than the
>> avatar itself (since the avatar's interface is IResource in this case),
>> or you may just want to use the session in order to implement getChild
>> and render appropriately.
>
>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?

>
>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.

>
>Actually, our resources are pretty dumb, as they only issue remote calls to an
>external service and don't hold any information. And, since our realm can't
>figure out whether a user can issue a particular call or not without actually
>sending a token to the remote service, a mind object seemed the right place
>to me... but I'd happy to be wrong :-)
>
>Anyway, sorry if I sound as if I'm trying to get a positive opinion for a
>decision we already made :-P it's just that I don't see how the other options
>would completely fit our architecture (which could be broken in the first
>case, of course).

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

Jean-Paul