-----Original Message----- From: twisted-web-bounces@twistedmatrix.com [mailto:twisted-web-bounces@twistedmatrix.com] On Behalf Of Jean-Paul Calderone Sent: Wednesday, July 01, 2009 2:20 PM To: Twisted Web World Subject: Re: [Twisted-web] HTTPAuthSessionWrapper render On Wed, 1 Jul 2009 13:34:41 -0700, Jared Gisin <jared.gisin@isilon.com> wrote:
Yes, I can file a bug.
Is there a reason why this HTTPAuthSessionWrapper isn't a mixin for resource.Resource?
As a mixin, what functionality would it be providing? [JG]: It would be providing resource authentication. You mix it into any subclass of resource.Resource and it makes that resource require HTTPAuth of some sort. The functionality it provides now is that arbitrary resources can be protected by HTTP authentication without being modified. I can't quite see how a mixin achieve that goal. [JG]: Which in my experience (lack of proper documentation) doesn't work for anything other than what you pass in as the root to site.Site(). Try appending a Child resource wrapped in HTTPAuthSessionWrapper and it fails to properly call .render() on the wrapped resource. The parent find the HTTPAuthSessionWrapper and calls render on that thing, which return an Unimplemented, which is my complaint.
I've shoehorned it into my own custom subclass of resource.Resource that could easily be done as a mixin (though not Ideal due to MRO problem if it's in the wrong order). Better would be to provide a proper HTTPAuthResource that does it. Thoughts?
I'm not really sure what you mean here. You actually mixed HTTPAuthSessionWrapper into a Resource subclass and got it to do something? That's surprising, and not the intended use. :) [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. _______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web