[Twisted-web] Session Based Security for PyAmf application

[Phil Christensen]

On Aug 18, 2008, at 4:07 PM, Shawn Church wrote:
> I want to store user data in t.w.s.Session to allow a persistent  
> logon.  As the login will be made with a PyAmf method call I do not  
> think that t.w.w.Guard will work because it appears to process the  
> login from POST data.   It is trivial to store the user data in the  
> session object with Request.getSession,  but is this a secure  
> method?  Could someone guess the session key and use it to forge  
> credentials?  Is there a better way to do this?

Whenever you're dealing with sessions over unencrypted HTTP, it it  
potentially possible to forge credentials. I don't know for sure  
whether guard checks the IP address of a request against the original  
one that created the session in the first place, but even that could  
technically be forged.

> The PyAmf examples send the username and password with every method  
> call.  I would prefer to use the session because the user can log-on  
> once for multiple windows/tabs.  The twisted PB security model seems  
> much more elegant then what is available for twisted.web.  Am I  
> missing something????


I know what you mean; there are a number of things I don't like about  
Nevow guard, although I have to say I haven't spent any time with  
twisted.web's guard, and I know there are some differences.

However, the only real difference between the PB and twisted.web  
security models is guard itself (versus the PB login() methods). They  
both use twisted.cred for dealing with authentication, which is an  
excellent implementation of a common requirement.

If you can get a decent familiarity with twisted.cred, you can  
implement just about any session mechanism you might like. For an  
example, you could check out my txOpenID project (https://launchpad.net/txopenid 
). In this case, I needed to handle sessions without adding redirects  
to the authentication flow, save session data in a relational  
database, and programmatically determine where to redirect an  
unauthenticated user.

My solution in this case was to create a superclass resource that all  
my authenticated resources would inherit from. This is almost  
definitely not the "Twisted way" to do this, but it works  
exceptionally well for my needs.

Hope this was some help,

-phil