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 _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
