in reply to Re: Session identification (was: Game).
in thread Game.

Passing the session ID through forms/links is an even better way of doing sessions - in theory it will even work with mobile phones and other really small broswers that don't do cookies. Full points for choosing the hard but more right way to do it.

I tend to avoid this option because it's too much work for this lazy programmer, and because passing that ID requires the program to rewrite every single URL on the page, and for me to train the graphics designers in how HTML::Template works.

I might give it a shot next time round, just to see how hard it is

In any case, Apache::Session::File will still make life easy for you, regardless of how you pass and retrieve the session ID. As I mentioned earlier, you could even use it to do things like save peoples preferences in a command line program. Not that you should do preferences like that, but you could.

____________________
Jeremy
I didn't believe in evil until I dated it.

  • Comment on Re: Re: Session identification (was: Game).

Replies are listed 'Best First'.
Re: Re: Re: Session identification (was: Game).
by Vynce (Friar) on Jun 06, 2001 at 05:30 UTC
    it also makes it possible for people to give you fake session ID's -- whether real ones that aren't theirs or just plain bogus ones. that could lead to trouble.
[reply]
      Yes, but if you give them 20-char session IDs, their chances of guessing someone elses are really quite low. Very, very low. Tiny, in fact.

      Of course, this doesn't stop someone hijacking their session. For this, you would want to send a different session number with every page, and only allow them to continue if you get it back with the request for the next page. Quite difficult to do, and very annoying for them if they want to browse in two windows at the same time. Or use SSL.

      ____________________
      Jeremy
      I didn't believe in evil until I dated it.

[reply]

        and if they go back 3 pages and do somethign different so that they are using the session ID from 3 requests ago, are they just out of luck?

        or, to be a little more explicit,
        actionsends session_ID
        user comes to siten/a
        server serves main pagen/a
        user logs inn/a
        server shows logged-in page123
        user requests page 52123
        server gives page 52456
        user requests page 52-c456
        server gives page 52-c135
        user requests page 52-f135
        server gives page 52-f237
        user hits "back" to go
        back to login screen
        and requests page 38        		123
        server was expecting 237 ... what does it do??

        this case, and others like it, make me think this method is unworkable. but maybe you see it differently; maybe i'm overlooking something, or maybe you just are willing to do more work than i am. but if it will continue to accept old session_ID's, then why bother changing them? and if it won't, i think a lot of people are going to be upset at the inability to "back".

[reply]

In Section Seekers of Perl Wisdom