[Twisted-web] HTTPAuthSessionWrapper render

[Jean-Paul Calderone]

On Wed, 1 Jul 2009 07:12:25 -0700, Jared Gisin <jared.gisin at isilon.com> wrote:
>I guess the problem that I have is that there's an example for it, where
>you wrap the root object that gets passed into a
>twisted.web.server.Site() instantiation. My application doesn't require
>auth for every thing in the site; only certain subtrees of the Resource
>hierarchy, so how in the world in a Resource's __init__(self): would I
>hook this up to something that I'd pass into self.putChild()
>
>Here, I've modified the realm to hand back the Resource object passed in
>upon authentication.
>
>site = server.Site(
>guard.HTTPAuthSessionWrapper(Portal(APIRealm(Root()), CRED_CHECKERS),
>	CRED_FACTORIES))
>
>
>But suppose I have under Root() a resource V1, then the following
>doesn't work:
>
>class Root(Resource):
>
>    def __init__(self):
>        Resource.__init__(self)
>
>        self.putChild('1', guard.HTTPAuthSessionWrapper(
>                       Portal(APIRealm(V1()), CRED_CHECKERS),
>                          CRED_FACTORIES))
>
>	  Self.putChild('', self)
>
>
>What winds up happening is that it things an instance of
>HTTPAuthSessionWrapper is the child of Root, and when I access a URI
>such as /1?blah, which I expect to render something, it winds up calling
>the render method of that HTTPAuthSessionWrapper, which is wrong. It
>needs to call render of V1(), not it's wrapper. What do I have wrong?

That sounds like a reasonable thing to be doing, in which case what you
said about HTTPAuthSessionWrapper.render passing through to the avatar
sounds like the right behavior.

Can you file a ticket in the issue tracker for this?

Jean-Paul