[Twisted-web] HTTPAuthSessionWrapper render

[Jared Gisin]

-----Original Message-----
From: twisted-web-bounces at twistedmatrix.com
[mailto:twisted-web-bounces at 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 at 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 at twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web