On Mon, 6 Jul 2009 10:37:39 -0700, Jared Gisin <[email protected]> wrote: > > [snip] > >[JG]: I didn't mix it in as I copied the functions directly and adapted >them to work directly in my resource.Resource subclass. I refactored my >mixin to be a custom resource.Resource that does what I want. It seemed >to me that HTTP Auth should be provided at the per-resource level. As >resource.Resource creates a hierarchy of resources, what I want to do is >mark a particular leaf as requiring HTTP Auth. I might also want to mark >an entire subtree as requiring auth by setting a flag on the parent >resource. Then, as the twisted starts parsing thru the URI resource >children from the root Resource, as soon as it hits a resource that >requires HTTP Auth, it would go off and perform the HTTP header >inspection and authentication processing, creating a Portal on the fly >with the avatar returned by the realm set to the next child. When the >login calls return, the getChildWithDefault continues on with the next >child avatar that was passed in to the realm when the requirement for >Authentication was hit while walking the resource tree for the incoming >URI. It seems hokey to "wrap" a resource in another resource, when in >reality, all it's doing is inserting a resource in the hierarchy. Parent >-> Child becomes Parent -> Wrapper -> Child. IT would seem wiser to have >a mixin or a proper HTTPAuthResource class that includes this >functionality without this extra "wrapper" layer. Such a properly >designed resource could include instantiation parameters that define the >type of authentication to be performed, passing in cred checkers, a >realm, portal, whatever is required for that resource. I'm probably >starting to mix in too much stuff into the base functionality, which as >I can see is why nevow implements a totally different resource model to >fit the needs of a web application. Likely I'm just as well off to roll >my own type of resources that behaves as I see fit for my purposes just >as nevow did. Either way, better documentation describing how the this >thing is indented to work would have saved me lots of trouble. I would >imagine that the core functionality of twisted would be designed to >support many different uses cases, not a single, undocumented use case. >
The gist of this seems to be that you prefer inheritance to composition, whereas I (and many other Twisted developers) prefer composition over inheritance. :) Aside from the bug which started this conversation, I think HTTPAuthResource can provide all of the functionality you're interested in. Jean-Paul _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
