On Mon, 6 Jul 2009 10:37:39 -0700, Jared Gisin
[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