http://qs1969.pair.com?node_id=472515


in reply to Re^2: "omniscient debugging" for Perl
in thread "omniscient debugging" for Perl

How does this eliminate the need for cookies? ... No matter how much you can save on the server side, HTTP is stateless and you need some piece of data coming from the client to indicate that this request is tied to a previous request ...
If you can represent the entire state compactly enough, you can send it back to the client with every response and receive it from the client with every request. Now you don't need to store any state on the server, nor do you need cookies on the clients.

For example, take a look at Web Authoring System Haskell. It records a journal of client-server interactions, sends this journal to the client as part of every response (in a hidden field in an HTML form), and when the form is submitted, it replays the journal on the server to recreate the state.

Cheers,
Tom

Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

  • Comment on Eliminate server-side state to obviate cookies

Replies are listed 'Best First'.
Re: If you do away with server-side state, you don't need cookies
by mpeters (Chaplain) on Jul 05, 2005 at 16:48 UTC
    Whether you send the data to the client as a hidden field in a form, or as a cookie it's basically the same thing. And by using a cookie you can be sure that the data will be in every request the user sends (GET's, links, images, media, etc) from then on, not just the results of a form.

    While this would reduce the need for server side storage of sessions, this can already be done. There are lots of people who instead of sending a session id in the cookie (or hidden field) will send a serialized version of an object or hash which they can then unserialize at the next request.

    -- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier
[reply]
      Whether you send the data to the client as a hidden field in a form, or as a cookie it's basically the same thing.
      Not really. The complete-state-in-a-form method allows for easy session forking. It also allows users to undo state transitions by backing up into the browser history. Cookies don't support either of these.

      Cheers,
      Tom

      Tom Moertel : Blog / Talks / CPAN / LectroTest / PXSL / Coffee / Movie Rating Decoder

[reply]
        Not really. The complete-state-in-a-form method allows for easy session forking. It also allows users to undo state transitions by backing up into the browser history. Cookies don't support either of these.

        Session forking isn't that hard with IDs (whether cookie or URL based). Just have the ID index into a tree of state transitions on the server side. It's something I've done on several sites (and I've a vague memory that somebody has implemented a CPAN module that makes doing this fairly simple, but am to lazy to go find it :-)

        Keeping the state server side can be handy, and having a small ID means I can stick it in a URL and have a more RESTful bookmarkable API.

[reply]
Re: Eliminate server-side state to obviate cookies
by hardburn (Abbot) on Jul 05, 2005 at 16:55 UTC

    This sounds horribly insecure to me. How do you stop the client from changing the state into one it shouldn't.

    I think I'll keep cookies with a randomly-generated ID crossreferenced to a database.

    "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
[reply]

        Then you switch from needing to store a session ID in a database to needing to store and manage a private key. Not only that, but I can't imagine the ending size being less than the 160-bits needed for SHA1 (or 256 or 512 bits, if you want more secure hashes).

        I'll continue looking for a solution that's better than cookies + secure ID + database.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
      How do you stop the client from changing the state into one it shouldn't.
      Encryption
      Storing the session state in the form sent back to the browser may have security implications if it reveals internal server information. In addition, the session state often contains sensible user input, like passwords. WASH/CGI addresses both concerns by providing a one-time pad encryption for the session state.

      20050705 Janitored by Corion: Moved (broken) link from a tag into [http://

[reply]
[d/l]
        People who talk about using one-time pads in practice are generally either military or idiots.

        It takes a lot of work to generate (and in many cases to communicate) a one-time pad. Any reuse of data (or use of low-entropy random number generators) ruins the entire concept entirely, resulting in something that cryptographers assure me is easily broken. The required effort is fine for the military. But very few commercial applications find it feasible.

[reply]

        I get nervous whenever anyone mentions "one-time pad". In any case, I still can't imagine this having significant savings over coookie + session ID + database.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]

In Section Meditations