On Thu, 19 Feb 2009 18:47:37 +0100, Esteve Fernandez <est...@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.
For example, if a user is allowed to access /foo, then you might represent
that by including {'foo': True} in the session somehow. Then, your can
have a getChild method which looks at that information if it is asked for
the "foo" child. If 'foo' is not associated with True, you can reject the
request, otherwise you can process it.
You can also use multiple different avatar classes to represent this.
Instead of keeping a session and referring to it when deciding whether
a particular request is acceptable, you may want to have a FooAvatar and
a NoFooAvatar. FooAvatar's getChild would always give back a resource
when asked for "foo", and NoFooAvatar never would. The only checking would
be in your realm, where you decide what kind of avatar to give back from
requestAvatar. This might imply that your realm is the right place to
keep your session data.
There are lots more possible approaches, of course, but these are two of
the most common.
Jean-Paul
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
