Preserving Settings during a user's session
Zopesters, I'm trying to accomplish something and I can't figure out an elegant way to do it. I need to preserve variables, like State=CA or ID=5, throughout a user's session, unless I specifically change them in a page (i.e. I change ID=5 to ID=4). I can think of two methods: a. Passing all the values in the link syntax for all page links: <a href=page_name?ID=5&State=CA&Region=1&Tab=Guide>Link text</a> b. Storing the values in cookies. I'd prefer not to use cookies as this will be a public web site and some people have privacy concerns about cookies. Anybody got a better idea? Jeff jeffniel@ix.netcom.com P.S. I've been Zoping for about a month now. Zope Rocks!
On Tue, Feb 23, 1999 at 10:16:27PM -0800, Jeff Nielsen wrote:
I need to preserve variables, like State=CA or ID=5, throughout a user's session, unless I specifically change them in a page (i.e. I change ID=5 to ID=4).
Anybody got a better idea?
Another option, one I've used a lot because it keeps things "clean", is to use HIDDEN fields in forms. Now this only works if someone clicks a "submit" button to go somewhere ,though... The other option, BTW, is to do something even funkier (a'la WebObjects) and create a session ID that is some huge number (let's pick 42 for this example :-) and you append it on (or insert it somewhere) to the whole thing: http://www.megacorp.com/foo/bar/user/42 What I like better honestly is this: http://www.megacorp.com/42/foo/bar/user What this would let you do is have the (flash of insight) ZPublisher insert the ID into the REQUEST object on the fly so that you could have access to it wherever you want, then rewrite the request to its more traditional form, following that path. This would require banning "numbers" as root folders, but seems reasonable. So onward and upward in idealogy (I've been thinking about this for a while, actually): * ID is hex signature of IP address and initial timestamp (a'la UNIX) passed through an MD5 filter. THis only needs to be one-way in my opinion, and for privacy, shouldn't go backwards. * You can pull this farther into "Session Objects" which can be persistent across visits (by using something else besides IP to look them up) and can contain any amount of information that the application needs. * Move one step further: Session Server, this could be shared among multiple Zope servers to allow perfect load-balancing,failover, etc. Wa'la... all that handwaving and it's done, eh? Now, honestly, I haven't a clue as to how to cram that into the ZPublisher, since i've not looked at the internals too much, but I trust the gang at DC to have done things "right" the first time :-) Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
Chris wrote: |> * ID is hex signature of IP address ... I hope you're not presuming that there is at most one user session, at any given time, per IP addr. What if there are multiple users working from a given client system -- think Unix or Linux here. ======================================================================= I won't rest till it's the best ... Software Production Engineer Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj
On Wed, Feb 24, 1999 at 07:49:50AM -0800, Paul Jackson wrote:
Chris wrote: |> * ID is hex signature of IP address ...
I hope you're not presuming that there is at most one user session, at any given time, per IP addr. What if there are multiple users working from a given client system -- think Unix or Linux here.
Ah, I guess I glossed over the idea ... these IDs are generated once, and I *AM* assuming that at any instantaneous point in time (i.e. subsecond accuracy) there are not two of them from the same IP address being generated :-) Actually, Linux/UNIX is hardly an issue any more for web servers, firewalls however, ARE :-) So if you had two people coming from Firewall A (192.168.1.1), so long as they got their IDs at lest a 10th of a second apart (or whatever accuracy time.time() returns) they'd always be unique. Make more sense now? :-) BTW, I've got to get an SHA1 implementation in the libraries, i Just don't like MD5. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
On Wed, 24 Feb 1999, Christopher G. Petrilli wrote:
Ah, I guess I glossed over the idea ... these IDs are generated once, and I *AM* assuming that at any instantaneous point in time (i.e. subsecond accuracy) there are not two of them from the same IP address being generated :-)
Actually, Linux/UNIX is hardly an issue any more for web servers, firewalls however, ARE :-)
So if you had two people coming from Firewall A (192.168.1.1), so long as they got their IDs at lest a 10th of a second apart (or whatever accuracy time.time() returns) they'd always be unique.
Make more sense now? :-) BTW, I've got to get an SHA1 implementation in the libraries, i Just don't like MD5.
Errr, could you hash in the user name as well so that we might even be able to further avoid that 10th of a second part. Heck why I'm at it (it being suggesting more work for others to do). Could we get these sessions to expire after a certain inactiviy period? And possibly map sessions to acl_user folders so that they don't have to re-login (as long as their sessions are valid) and so that we can replace that ugly browser dialog box with a pretty web page of our own design? --------------------------------------------------- - Scott Robertson Phone: 714.972.2299 - - CodeIt Computing Fax: 714.972.2399 - - http://codeit.com - ---------------------------------------------------
On Thu, Feb 25, 1999 at 02:43:53PM -0800, Scott Robertson wrote:
Errr, could you hash in the user name as well so that we might even be able to further avoid that 10th of a second part.
Well, a quick test on my machine at least, generating 1M sample from the time counter as fast as I can in Python, the interval necessary to break the counter would be 1/100th of a second. And this would then require that they both be originating from the same IP address as well. Now, please understand this concept of "session" is more for tracking a user through the site, rather than authenticating the user... it could be used for that by attaching authentication information to the SessionID object referenced.
Heck why I'm at it (it being suggesting more work for others to do).
Always happy to handwave more, it's largely free... except for the CTS ;-) I'll send a bill!
Could we get these sessions to expire after a certain inactiviy period?
Well, that shouldn't be that hard, just need to reap the database on occasion.
And possibly map sessions to acl_user folders so that they don't have to re-login (as long as their sessions are valid) and so that we can replace that ugly browser dialog box with a pretty web page of our own design?
Well, this would be seperate I think... not sure, honestly, gotta think on THIS one ... how to integrate the user objects together. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
On Wed, 24 Feb 1999, Paul Jackson wrote:
I hope you're not presuming that there is at most one user session, at any given time, per IP addr. What if there are multiple users working from a given client system -- think Unix or Linux here.
Not to mention many offices, etc, NAT through a single IP. Isn't there a way to tickle Apache and get it to provide a session ID? Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations
On Wed, Feb 24, 1999 at 11:16:37AM -0500, Mike Pelletier wrote:
On Wed, 24 Feb 1999, Paul Jackson wrote:
I hope you're not presuming that there is at most one user session, at any given time, per IP addr. What if there are multiple users working from a given client system -- think Unix or Linux here.
Not to mention many offices, etc, NAT through a single IP. Isn't there a way to tickle Apache and get it to provide a session ID?
There is an optional module which can do this, but I think I'd rather see it handled in Zope personally, then it doesn't matter what web server you use (Medusa, Apache, Netscape, IIS) or even multiple selections from that set on different machines using the same backend database to store session data in :-) Just my 2 cents. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
Mike Pelletier wrote:
Not to mention many offices, etc, NAT through a single IP. Isn't there a way to tickle Apache and get it to provide a session ID?
How about from a single long-running process on a well known URL? Sessions could then be scaled beyond a single server. Jeff Bauer Rubicon, Inc.
On Wed, Feb 24, 1999 at 10:39:57AM -0600, Jeff Bauer wrote:
Mike Pelletier wrote:
Not to mention many offices, etc, NAT through a single IP. Isn't there a way to tickle Apache and get it to provide a session ID?
How about from a single long-running process on a well known URL? Sessions could then be scaled beyond a single server.
This was my point with the concept of a SessionServer, which would be something seperate from Zope's main database. It would reside on a central server, and allow for multiple servers to resolve IDs into "Session" objects. These objects could even maintain state for some period of time after their last access (i.e. someone could be shopping, leave and come back in some manner)... you could also retreive them based on some other information, perhaps... a userid, or something. Honestly, though, I'm not sure HTTP is the best protocol for this, but what do I know... I'd use XML-RPC over HTTP if I did that, otherwise I'd use something else like CORBA. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
"Christopher G. Petrilli" wrote:
How about from a single long-running process on a well known URL? Sessions could then be scaled beyond a single server.
This was my point with the concept of a SessionServer, which would be something seperate from Zope's main database. It would reside on a central server, and allow for multiple servers to resolve IDs into "Session" objects. These objects could even maintain state for some period of time after their last access (i.e. someone could be shopping, leave and come back in some manner)... you could also retreive them based on some other information, perhaps... a userid, or something.
I was thinking more initially about just a ticket dispenser, than a session manager. It's purpose would be to assure a unique id is passed to each requestor, possibly storing some information passed to it during the request phase. Session management would be a separate process.
Honestly, though, I'm not sure HTTP is the best protocol for this, but what do I know... I'd use XML-RPC over HTTP if I did that, otherwise I'd use something else like CORBA.
The main problem is getting all this stuff to work through proxies, I'm sure you're aware. I actually did manage to get Iona's Orbix to work through a firewall (thanks to hecurlean efforts on the part of Justin Mason @ Iona and a security guru at Sprint), but it's just not worth the effort. Nor does the current xml-rpc work through a proxy, at present (although it shouldn't be difficult to fix). HTTP/SSL pretty much works everywhere. Best regards, Jeff Bauer Rubicon, Inc.
On Wed, Feb 24, 1999 at 11:06:43AM -0600, Jeff Bauer wrote:
"Christopher G. Petrilli" wrote:
How about from a single long-running process on a well known URL? Sessions could then be scaled beyond a single server.
This was my point with the concept of a SessionServer, which would be something seperate from Zope's main database. It would reside on a central server, and allow for multiple servers to resolve IDs into "Session" objects. These objects could even maintain state for some period of time after their last access (i.e. someone could be shopping, leave and come back in some manner)... you could also retreive them based on some other information, perhaps... a userid, or something.
I was thinking more initially about just a ticket dispenser, than a session manager. It's purpose would be to assure a unique id is passed to each requestor, possibly storing some information passed to it during the request phase.
I don't see wherewas this is really a different issue, honestly. Whether it's persistent or not is a different question, but that seems to be the only different in my view.
Honestly, though, I'm not sure HTTP is the best protocol for this, but what do I know... I'd use XML-RPC over HTTP if I did that, otherwise I'd use something else like CORBA.
The main problem is getting all this stuff to work through proxies, I'm sure you're aware. I actually did manage to get Iona's Orbix to work through a firewall (thanks to hecurlean efforts on the part of Justin Mason @ Iona and a security guru at Sprint), but it's just not worth the effort. Nor does the current xml-rpc work through a proxy, at present (although it shouldn't be difficult to fix). HTTP/SSL pretty much works everywhere.
So why wouldn't XML-RPC work across HTTP? This was my option, not across some other protcol. Heck, ILU work across HTTP and I've heard of people making it work thru firewalls. XML-RPC though on thought does seem like a good option, since it's standards based, and relatively light-weight. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
On Wed, 24 Feb 1999, Christopher G. Petrilli wrote:
So why wouldn't XML-RPC work across HTTP? This was my option, not across some other protcol. Heck, ILU work across HTTP and I've heard of people making it work thru firewalls. XML-RPC though on thought does seem like a good option, since it's standards based, and relatively light-weight.
Excuse me, for I am ignorant in the ways of XML. How would this be implemented on the client's end? Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations
On Wed, Feb 24, 1999 at 12:25:57PM -0500, Mike Pelletier wrote:
On Wed, 24 Feb 1999, Christopher G. Petrilli wrote:
So why wouldn't XML-RPC work across HTTP? This was my option, not across some other protcol. Heck, ILU work across HTTP and I've heard of people making it work thru firewalls. XML-RPC though on thought does seem like a good option, since it's standards based, and relatively light-weight.
Excuse me, for I am ignorant in the ways of XML. How would this be implemented on the client's end?
My handwaving continues :-) No no my comment was directed to the server->session-server communications... the client will still only talk pure unadultered mother's milk-quality HTTP :-) Here's a better explanation, I hope... 1. User connects to a server for the first time, requesting a URL: http://www.megacorp.com/support/ 2. The Zope system realises that the REQUEST object doesn't have a SessionID attribute, and creates one (a SessionID) and sends a redirect to load: http://www.megacorp.com/42/support/ where 42 is the SessionID. 3. From then on the SessionID is stripped out of hte URL path, placed in the REQUEST object, and the rest of the path traversed, with the sessionID available to all objects thru the REQUEST object. Make more sense? Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
On Wed, 24 Feb 1999, Christopher G. Petrilli wrote:
Here's a better explanation, I hope...
1. User connects to a server for the first time, requesting a URL:
http://www.megacorp.com/support/
2. The Zope system realises that the REQUEST object doesn't have a SessionID attribute, and creates one (a SessionID) and sends a redirect to load:
http://www.megacorp.com/42/support/
where 42 is the SessionID.
3. From then on the SessionID is stripped out of hte URL path, placed in the REQUEST object, and the rest of the path traversed, with the sessionID available to all objects thru the REQUEST object.
42 maps to a temp object in the ODB right? and Why strip the ID out of the URL?
I was thinking more initially about just a ticket dispenser, than a session manager. It's purpose would be to assure a unique id is passed to each requestor, possibly storing some information passed to it during the request phase.
I don't see wherewas this is really a different issue, honestly.
In my particular situation I might have more than one way to manage the sessions, but would be willing to use a single session id assignment system. It may be that the difference between assignment and management collapses and I'm talking about a single management layer, but I think I'll keep them separate for the time being.
Whether it's persistent or not is a different question, but that seems to be the only different in my view.
By persistent, you are referring to the session state or the session id? [ stuff about firewalls/proxies ]
So why wouldn't XML-RPC work across HTTP? This was my option, not across some other protcol. Heck, ILU work across HTTP and I've heard of people making it work thru firewalls. XML-RPC though on thought does seem like a good option, since it's standards based, and relatively light-weight.
About the only thing I'm confident these days working across the myriad kinds firewalls (and what passes for firewalls) are: http, ftp, telnet (though usually disabled if the administrator has any authority) and (usually) ssl. Stating that a particular protocol runs on top of http isn't an automatic guarantee that it will work across http proxies. Visigenic's Visibroker fails (although I had to set up a demonstration to convince them) on their client-side http tunneling. People who have gotten ILU to work across firewalls may have had more success than I, apparently. My experiences are also about 12 months dated. I don't doubt that any given protocol (e.g iiop) can be made to work across any given firewall, but I don't have the time or resources to concentrate on this effort -- if any applications are to ever get written. ;-) All this may be water under the bridge, given your useful followup message to Mike Pelletier.
my comment was directed to the server->session-server communications.
This being the case, my comments regarding firewall issues are hardly relevant. --- interlude --- Long-term, I'm not comfortable with making distinctions between clients (where a client is always assumed to be a browser) and servers, except as roles that distributed objects adopt at different times. xml-rpc may offer some interesting ways to address these issues. My own (limited) experience suggests that it may require some effort before objects can easily communicate across firewalls. I welcome anyone else's thoughts on this subject. Disclaimer: I am not a firewall/security/network protocol specialist. Please feel free to view all comments above with suspicion or even outright disbelief. Best regards, Jeff Bauer Rubicon, Inc.
On Wed, Feb 24, 1999 at 01:58:14PM -0600, Jeff Bauer wrote:
I was thinking more initially about just a ticket dispenser, than a session manager. It's purpose would be to assure a unique id is passed to each requestor, possibly storing some information passed to it during the request phase.
I don't see wherewas this is really a different issue, honestly.
In my particular situation I might have more than one way to manage the sessions, but would be willing to use a single session id assignment system. It may be that the difference between assignment and management collapses and I'm talking about a single management layer, but I think I'll keep them separate for the time being.
Maybe we're crossing wires, but I think we're talking about the same thing here... basically your "ticket" is my "sessionID" we then get into the discussion of whether or not this information is persistent across time (and if so, how much). Obviously this information must be persistant across SOME value of time for it to be of any value. The question for me is whether or not this piece of information should bring with ti OTHER information referenced with the sessionID as an index. Hmm, how to explain this :-)
Whether it's persistent or not is a different question, but that seems to be the only different in my view.
By persistent, you are referring to the session state or the session id?
They are implicitely the same... a "session state" is just an object associated with a specific session ID.
[ stuff about firewalls/proxies ]
Now this is just handwaving at this point, but XML-RPC is just a new mime-type, nothing more. So as long as your firewall doesn't filter based on mime-type, or allows you to determine which ones... you should be OK. This would be no different than filtering based on image/gif, or something along that lines. I believe the MIMe type in question is text/xml.
Long-term, I'm not comfortable with making distinctions between clients (where a client is always assumed to be a browser) and servers, except as roles that distributed objects adopt at different times. xml-rpc may offer some interesting ways to address these issues. My own (limited) experience suggests that it may require some effort before objects can easily communicate across firewalls. I welcome anyone else's thoughts on this subject.
I agree, but for the foreseeble future, my crystal ball says HTTP/HTML will continue to dominate the client/server level... what is more interesting from a Zope perspective is teh server/server middle tier, which will probably move toward a combination of CORBA and XML. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright
participants (6)
-
Christopher G. Petrilli -
Jeff Bauer -
Jeff Nielsen -
Mike Pelletier -
pj＠sam.engr.sgi.com -
Scott Robertson