[Twisted-Python] New web project
My first post to the TwistedMatrix list. ;-) By way of introduction, I worked on Persistent CGI for Bobo, Digital Creations' precursor to Zope. I'm still using a modified version of Bobo/PCGI under Apache for current applications and would like to consider switching to Twisted. Let me first say that I'm very impressed with the Twisted framework. Although I've not written any servers yet, I was able to get a secure SSL web service running soon after I downloaded the code. (Someone please remind me to write a quick How-To.) What follows is a description of how I'd like to use Twisted. A Use Case, as it were. I'm specifically solicting responses of the kind: R1: "That's already a standard idiom in Twisted." R2: "You can already do that in Twisted, but it may not be obvious. Here's how: ..." R3: "You *could* do that, but here's a better approach ..." R4: "Twisted doesn't presently support that function, but here's what would be required to provide it ..." --- Actors: User, User-session, Facility 1. Each Facility would be handled by a single long running process (LRP). Currently we handle each User-session in an LRP, which actually simplifies session management somewhat, but makes other things at the application level more complicated. 2. Users would access their facility via URLs of this kind: http[s]://facility1.site.com http[s]://facility2.site.com Twisted would dispatch this traffic to the appropriate Facility LRP, which is effectively a Twisted web server. Each server (Facility) is running on a different port. 3. Users would be authenticated in a manner similar to Apache's htpasswd mechanism, and a User-session is created. Currently, since all session work occurs under SSL, I have access to the REMOTE-USER environment variable. 4. I presently drop a Cookie in the User's browser representing the ID of the User-Session. From reading Itamar's posting (Dec 17 2001), I gather that I should consider sessions rather than cookies. Thanks in advance for any replies. Jeff Bauer Rubicon Research
On Thursday, October 10, 2002, at 01:59 PM, Jeff Bauer wrote:
Actors: User, User-session, Facility
1. Each Facility would be handled by a single long running process (LRP). Currently we handle each User-session in an LRP, which actually simplifies session management somewhat, but makes other things at the application level more complicated.
One way to handle this would be to have Apache do a ProxyPass in a VirtualHost directive to Twisted instances running on different ports. I do this where I work, and it works very well. A better way to do it is with twisted.web.vhost.NameVirtualHost. I have not used this, but it occurs to me I should, because looking at the code it really is very simple. However, since you also have the requirement that each Facility be it's own LRP, you may also need to learn about twisted.web.distrib if you go this route. I will defer to someone who knows more about vhost and distrib on this one. <snip -- someone who knows more about distrib and authentication please reply>
4. I presently drop a Cookie in the User's browser representing the ID of the User-Session. From reading Itamar's posting (Dec 17 2001), I gather that I should consider sessions rather than cookies.
Sessions are implemented behind the scenes as a cookie. Since it is very simple to request a session from the request object (request.getSession()), and it handles the cookies for you, I recommend doing that. Hope this helps a little! Donovan
participants (2)
-
Donovan Preston -
Jeff Bauer