|
Re: Re: Game.
by jepri (Parson) on Jun 04, 2001 at 16:30 UTC
|
That really is only a partial solution. It's a good rule to NEVER store any information on the clients browser. In a game it doesn't matter too much, but it allows the user to change the values you store so that the gain unfair benefit.
For instance, if you set a cookie called 'gold' with value '10' I could edit my cookie file and give myself 1000000 gold.
The proper way to do it is to hand a unique string (such as provided by Apache::Session) to the browser as a cookie. When they return it, load their data from the backing store.
This stops users from tampering with the information. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] |
|
|
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
| [reply] |
|
|
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] |
|
|
|
|
|
|
|
All I wanted to use the cookie for was for their username,
All I really need the game for is my class project and my teacher has little to no understanding of perl.
so I doubt he will change the value of the username cookie.
Oh and I won't be running it on a apache server
| [reply] |
|
|
Not all the Apache modules need the Apache server. This one doesn't. It can even be used from the command line.
And this is probably closer to the 'right' way to do it, which is good practise for if you ever decide to do some real programs in Perl. ____________________
Jeremy
I didn't believe in evil until I dated it.
| [reply] |
How
by Anonymous Monk on Jun 04, 2001 at 16:31 UTC
|
how would I go about using that? | [reply] |
RTFM
by davorg (Chancellor) on Jun 04, 2001 at 16:33 UTC
|
| [reply] |