cookies for HTTP session tracking

Paul Boddie paul at boddie.net
Thu Jan 10 11:18:11 EST 2002


Michael Ströder <michael at stroeder.com> wrote in message news:<3C3D6C7C.34D5DF11 at stroeder.com>...
> Alex Martelli wrote:
> > 
> > No, but there is a _different_ solution (not necessarily _better_!-):
> > <INPUT TYPE="HIDDEN" VALUE="sessionidgoeshere" NAME="MYHIDDEN></INPUT>.

[...]

The XMLForms for Webware package that I've been working on does this,
but for all data within a session. It's therefore possible to have a
multi-screen interaction whose state is maintained within the
request/response dialogue. Of course, the primary motivation for this
is my perverse interest in seeing whether it can be done sensibly, but
there are arguably side-benefits: there's no need to store session
state "on the server", and the state of the user's interactions is
correctly represented when going back and forward in the browser's
"navigation stack" (unless there are side effects of the user's
activities).

> It does work without forms though the hidden parameters show up in
> the query string of the URL. Your application might wanna construct
> the URLs including the query string and put it in <A HREF="...">
> (urlib.quote() is needed off course). E.g. Google does it that way
> for generating the URL for switching between the different search
> forms while keeping the search values.

To do this in my framework effectively requires "special links" which
encode the data in the way described above. Alternatively, one could
just make sure that no hyperlinks are to appear in the application.
;-) (This is acceptable for certain kinds of applications, though.)

One challenge of performing the above work is knowing where in a Web
framework to put the code which inserts the various HTML elements, or
even whether it's appropriate to insert HTML elements into content.
XMLForms demands adherence to the definition format which dictates the
output (amongst other things), so it's obvious how and where the
insertion activities fit in.

> Some people here claim that it makes problems with the user
> bookmarking the URL including the session ID. Well, then one has to
> rethink how the session handling is done. If the user comes with an
> invalid session ID simply give him a new one.

It is indeed irritating when people (especially online news sites)
refer to articles on (other) sites which appear unaccessible because
of spurious session information encoded in the URL given.

Paul



More information about the Python-list mailing list