Hello, I'm wondering about the chance to create multiple sessions with guard, on the same host:port. The idea is: i set up an apache proxy that, depending on the first segment of the url requested (/foo or /bar, for example) will forward client requests on different twisted-nevow applications, running behind. Now, it seems to be a good idea, because the root resource associated with each request will depend on the first segment. The problem is: each twisted-nevow application will want to create a cookie to handle the session. Being these cookies related to the same host:port, the different twisted-nevow applications will be in conflict, maybe overwriting the cookies created by their friends. Is this correct? Or cookies depend on the url? Are browsers aligned on cookies handling? Or is it possible to expect a different behaviour from different clients? -- efphe Today is Setting Orange, the 61st day of Bureaucracy in the YOLD 3174
On 2008/10/07 10:55 PM Federico Tomassini wrote:
The problem is: each twisted-nevow application will want to create a cookie to handle the session. Being these cookies related to the same host:port, the different twisted-nevow applications will be in conflict, maybe overwriting the cookies created by their friends.
I'm not sure I agree with your deployment idea. Why not just link these applications off the same process instead of complicating it behind Apache? Regardless of the reasons for that (I'm sure you have some) it's perfectly possible to override the cookie created for Guard. It should be easy to add a prefix for each if you override the SessionWrapper object. From looking at it though, the actual session key is a randomised hash not at all based on the hostname or port so it will not conflict between different guarded instances. Logically this is a good design because nothing stops you from having numerous different guard instances in one app. Read the source :)
Colin Alston wrote:
On 2008/10/07 10:55 PM Federico Tomassini wrote:
The problem is: each twisted-nevow application will want to create a cookie to handle the session. Being these cookies related to the same host:port, the different twisted-nevow applications will be in conflict, maybe overwriting the cookies created by their friends.
I'm not sure I agree with your deployment idea. Why not just link these applications off the same process instead of complicating it behind Apache?
The architectural problem is: different logins have to raise different resources. On the same fqdn, because we use a SSL certificate for it. For now, we are using different ports and different nevow application behind each port. Now, we have the need to serve multiple applications not only the same host, but also on the same port. What do you mean with "link these applications off the same process"? Is your idea compatible with these needs?
Regardless of the reasons for that (I'm sure you have some) it's perfectly possible to override the cookie created for Guard. It should be easy to add a prefix for each if you override the SessionWrapper object. From looking at it though, the actual session key is a randomised hash not at all based on the hostname or port so it will not conflict between different guarded instances. Logically this is a good design because nothing stops you from having numerous different guard instances in one app.
Read the source :)
waiting for an answer i was doing this: reading SessionWrapper sources. Yes, cookieKey seems to be there for this purpose and, when it's not specified during SessionWrapper initialization, it's a random hash. That seems to solve my problem: i need only to complicate apache, proxy-ing requests (depending on the first segments) and redirecting them to different applications. -- efphe Today is Setting Orange, the 61st day of Bureaucracy in the YOLD 3174
participants (2)
-
Colin Alston -
Federico Tomassini