[Twisted-web] Get identity of previously-authenticated user

Mike Pelletier mike at mkp.ca
Fri Apr 22 10:26:02 EDT 2011


Thanks for the feedback, Glyph.  You ask, "how could you be so dumb?"
so I will explain.  (You also said the A-word, but I will ignore
that.)

Conceptually, it is the HTTP request that is being authenticated.  I
thought it was therefore quite neat and tidy to register PB-style
avatar objects as a components of the request itself.


My resource objects do not have any member data that allows them to be
dangerous.  They manipulate the persistent state of the application
via avatar objects, which they don't get until getChild() or render().
 I do have to perform access checks in my methods like you mention,
but only for cosmetic reasons.  If I fail to do so, the harm can be no
greater than a TypeError or AttributeError raising.

It does turn out that the access check happens at a more inconvenient
time to do anything about it than when in requestAvatar.  No surprise
to you I am sure.  I think I did not fully grasp the role of the Realm
as I was working on this. I imagined that the Realm was meant to be a
gatekeeper to an already-instantiated resource it didn't really know
anything about, but I guess it really encapsulates a lot (all?) of the
security policy, so it has to have some knowledge about the resources
its dealing with.

I liked that my resources did not have to know very much; what
children they happen to have plugged into them, who is logged on, what
data their children will need for configuration, etc.  They are
extremely simple and focused on their domain.  It made it feel like I
was doing the right thing.

I build the tree in my tac, rather than in my resource ctors.  I use a
small number of Resource classes for a somewhat larger number of
resources, with the tac containing the distinguishing configuration
data.  The tree is (so far) entirely static.   I do anticipate
deploying multiple tacs with different resource trees.  It is
convenient that resources are simple and stupid when plugging them
together.

There's really no reason I can't wrap the resource tree construction
up in a function I can pass to the Realm except that I would have to
change every ctor to pass down the user object to the smallest
crinkles of the tree.

I did not mean to malign twisted.web.guard.  The problem I ultimately
encountered with it was not due to a defect but a lack of foresight on
my part.  I grabbed it without looking at it closely, thinking that it
would get me up quickly, and then through the magic of twisted.cred, I
would be able to grow it into whatever authentication system I needed
(ie, friendly form-based login).  This is not the case, since the
challenge/response machinery belongs to the resource wrapper object
(ie, informally, "twisted.web.guard") and it would never be very
adaptable to my needs.

I am now using my own root resource to set up PB-style avatars on the
session.  I plan to expire any sessions referenced via cleartext http.
 I can't wait to see what goes wrong with that.

--Mike



More information about the Twisted-web mailing list