On Monday 06 May 2002 10:30, Lincoln Yeoh wrote:
> At 09:56 AM 5/6/02 +0200, Peter Conrad wrote:
> > > I've written a lot of webapps, and I can tell you that quite
> > > often it ends up that you need to pass a value back in a form that
> >
> > won't be
> >
> > > built until a later step in a process, or you need to have the page
> >
> > remember
> >
> > > where it came from so you can go back, and its pretty common to do that
> > > by tacking it into the query string of the intervening page.
> >
> >A better approach usually is to store in the session object. Of course,
> >not all environments have session objects.

Well, yeah, most of the time the session object is a better idea, but there
are a few times, like switching between http and https where you can't easily
track the session id across, except to URL encode it temporarily, which is
the sort of situation I'm talking about.

As a for-instance, I have an 11 step sign up form (this is not a joke, its
really 11 pages long :() and at the end we need to switch to https to finally
submit the entire thing... Not only that but I need to have a few flags
passed along telling the submission form what some of the earlier choices
were so it can post. Its a bit ugly example, but it is the sort of thing that
happens pretty often.

>
> What happens if a user opens more than one browser window and uses the same
> session? How would that work?

Shouldn't be a problem. You just need to make sure you access your session in
"safe" ways. One thing you will normally need to do is provide locking on the
session object to serialize access. Apache::Session provides all the needed
functionality if you're using perl (its designed for mod_perl but it works
fine in any script).
>
> I personally tack on the stack as an encoded parameter (modified base64 no
> real checksums tho - I figure if the user wants to mess up his session
> that's fine). The stack parameter is encoded so there shouldn't be a
> problem if the url appears elsewhere undecoded. This is of course an ugly
> solution.
>
> A more controlled solution would probably involve in giving _each_ http
> request its own request_id and then linking the various stacks with the
> request_ids. But for now the pain vs gain ratio isn't attractive ;).

Seems like a fairly elaborate mechanism. Any information that only needs to
exist during the processing of a single request is just a variable in your
script somewhere... Other bookkeeping you should be able to do just based on
the session id, though you might fall back on a URL param or Cookie to help
you sort out which window is at what point in a complicated form sequence or
somesuch (or again, where you switch to https and loose your cookie).
>
> Cheerio,
> Link.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]