[Twisted-web] HTTPAuthSessionWrapper render

[Jean-Paul Calderone]

On Mon, 6 Jul 2009 10:37:39 -0700, Jared Gisin <jared.gisin at isilon.com> 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