in reply to Re: Re: Game.
in thread Game.

Thank you for reminding me - and us - of bigger picture.

When I first read the question between new nodes, I thought: " Jeez, this is easy one, even acolyte as myself can answer it and help fellow monk". So I did.

Sure enough, my answer should be: "Please read CGI::Cookie while more experienced monks will answer with more detailed insight".

I am guilty being not enough patient and humble about my beginner's perls skills.

But my answer was not completely wasted, it prompted you to write this more detailed insight as compared with my (too) simple solution proposed.

I discussed similar issue with colleagues, so I should be aware that cookie will not final solution. We decided not to use cookie at all, because for some unknown reason some users do not want to accept cookie - or at least pretend not to accept cookie when asked about it. So we have login/password combination, which will create session, and sessionID we will pass to every form page instead of userID. This should allow to identify users/sessions even without cookies and with unlimited amount of protected information. We also wanted to prevent users to use bookmarks instead of proper login. Still we need session to expire - we'll do it on server side.

Does it make sense?

pmas

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

Replies are listed 'Best First'.
Re: Re: Session identification (was: Game).
by jepri (Parson) on Jun 06, 2001 at 05:11 UTC
    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.

[reply]
      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]

In Section Seekers of Perl Wisdom