d_i_r_t_y has asked for the wisdom of the Perl Monks concerning the following question:

i've just been initiated into the wonderful world of maintaining state and sessioning with the Apache::Session module. Works great, though there is a steep learning curve on the more practical aspects of sessioning.

My question relates to the most practical way to keep multiple sessions open at one time, such as when the user may have multiple browser windows open performing simultaneous queries and the like. The nature of the web site is that a user makes an initial query, but then can subquery the results of a previous query to refine their results.

I am using a single session cookie to pass around a session id between scripts, however each invocation of a script with the same session id 'pollutes'/invalidates other currently open sessions. i am hesitant to take the approach of just storing every CGI request parameter in the one session hash, working out what query extends what query, and then artificially constructing the complete query from a 'cgi-parameter history'.

i'm sure this could be done much better -- maybe by using a new session id for every request and keeping a reference to the 'parent' session for each request? how else does one spin off multiple derivative sessions without disturbing other existing/past sessions? wisened monks please advise...

thanks, matt

  • Comment on practical aspects of sessions and state

Replies are listed 'Best First'.
Re: practical aspects of sessions and state
by merlyn (Sage) on Oct 17, 2000 at 06:25 UTC
    Don't use cookies as a session tracker. There are other methods for persistent state, such as mangled URLs and hidden fields that track a conversation rather than a browser. See Adding "state" to HTTP for previous postings I've made on this.

    -- Randal L. Schwartz, Perl hacker

[reply]
      I don't see why so many people hate cookies (or advise not to use them).

      I have the same problem here, I wrote a webmail app using Apache::Session to keep track of users. The session ID goes back out in a cookie, but all my coworkers said "Why the hell do you use cookies? Use hidden fields!". But sometimes I don't want to set up a FORM tag to provide some action - users can click on a link to read a mail for instance. So, if I put the session ID into the link (to get to it via GET) and someone reads a mail with a link inside (URLs in mails are getting autoconverted to links) and hits the link - voila, the session id is stored on the remote server in the referer log. Ok, this would work only for ten minutes (until the session expires) but that was the way that gmx.de was hacked - 1600 accounts lost their passwords.

      Sometimes one doesn't get away without cookies trivially.
[reply]
        Hmm. I don't know why you went off on the "cookies" thing. The problem here is that d_i_r_t_y wants to have two parallel conversations within one browser, and you can't do that purely with cookies, because the browser will happily send the identically same cookie to both "session" hits. So you can't use cookies or basic auth, and that means you're stuck with mangled URLs or hidden fields. That, or PSI::ESP, which hasn't been uploaded yet, but I have a feeling it will shortly.

        As for why some people "hate cookies (or advise not to use them)", I can give you my take on that. Cookies used for long-term authentication presume the demonstratably false statement of "one user is one browser", as opposed to session cookies, which I actually consider OK unless it breaks something like in d_i_r_t_y's case.

        In a given day, I'm popping back and forth between three or four browsers, and some of the browsers I use are on other people's machines, especially in internet cafes and such. So if you're crazy enough to use cookies for auth:

        1. be sure to give me a way not to do that if I know I'm in a shared-browser place
        2. time out the cookie at one day or less (in case I forget to "log out" at an internet cafe in the city I just left)
        3. make it very clear that I'm "logged in"
        4. make it very easy to "log out"
        5. make it very easy to "log in" on another browser
        6. make it possible to use the site entirely without cookies for the very paranoid.
        As a good model, look at Amazon. When I'm logged in, at the top of each page it says "If you're not randal, click here". Very clear to me that Amazon thinks my browser is me. And it's easy to log back in on a different browser, and log out on this one. And the site works without cookies at all (if I recall) because they give a session ID in a mangled URL for the particular shopping cart: I just don't get my preferences or "One-Click(tm) Shopping".

        Because of that last point, you've got to provide a mangled URL or hidden field solution anyway. So the easiest way out is to go ahead and presume "no cookies", and then slowly add in to the design a way of having longer term recognition, as long as you stay within the guidelines above.

        -- Randal L. Schwartz, Perl hacker

[reply]
Re: practical aspects of sessions and state
by jeorgen (Pilgrim) on Oct 17, 2000 at 16:35 UTC
    Does it matter if several browser windows are treated as belonging to the same session? Yeah, I suppose it can.

    Problem is, WWW has a very dim view on what a window is. Sometimes it can have a kind of id (with javascript):

    <A HREF="/public/Details/2451819_1.html" TARGET = "_new" onClick="wind
+ow.open('/public/Details/2451819_1.html','600175392813981','height=17
+5,width=300,scrollbars=1,alwaysRaised=1,resizable=1');return false">

    [download]
    But if the user clones a window I suppose this id will be duplicated?

    When the application through the user's action changes state, the application should check that this state change is possible.

    Part of the information for that might come from the session object, where there could e.g. be a different sort order preference for different windows.

    One solution could be to give new
    hidden field/cookie/mangled path
    for each new action the user takes, or state he puts the application in. Yeah, that's probably the way to go:

    Make changes to the session object to reflect new state and bind the updated object (and hence the state) to a new session id.
    Wreaks havoc with the "back" button though.

    But what happens to old rogue windows with old rogue session objects, could they nullify state changes if the user makes actions from them? I suppose this depends on the state change handling on the server side. If one is careful to code what data affects the user interface only and what parts actually do transactions that may be enough.

    /jeorgen

[reply]
[d/l]
Re: practical aspects of sessions and state
by elwarren (Priest) on Oct 17, 2000 at 18:45 UTC
    A good example of why NOT to use cookies is the WinAmp site. Try this:
    • Browse skins
    • Open new window in new category
    • Click next in previous window
    • This should take you to what should be the next page for the other window.
[reply]
      yep... this is almost exactly my problem... a user makes a query and then will probably subquery those results or redirect them into other intergated tools on the site. i for one always browse with multiple browser windows (doesn't eveyone) so that my next pages are coming down while i'm reading through my downloaded pages. i would definitely like to allow this behaviour with my site also.

      thanks for the reply...

[reply]

Back to Seekers of Perl Wisdom