|
Re: Game.
by jepri (Parson) on Jun 04, 2001 at 16:21 UTC
|
You don't explicitly state it, but you appear to be programming a web game. By far the best module for the job is Apache::Session::File or Apache::Session::Database.
For each new player, create a session file and return the name of the session as a cookie (the session 'name' is a 20 char string). When they go to the next page, read their cookie and load the session, then read their values out it.
The documentation for Apache::Session goes into this in detail.
Make sure you do a search on CGI at search.cpan.org to find lots of juicy modules that will make you task easy.
Realistically, you should be able to implement this part of the program in 2-3 hours. ____________________
Jeremy
I didn't believe in evil until I dated it. | [reply] |
Re: Game.
by fenonn (Chaplain) on Jun 04, 2001 at 19:40 UTC
|
If you are planning on using any HTML to display the game you could always put (a) hidden form field(s) in the document to pass any info you need from page to page.
print $query->start_form(-method=>$method,-action=>$action,-enctype=>$
+encoding);
print $query->hidden(-name=>'hidden_name');
print $query->endform;
You should be able to use that code, with slight modification, to create filds that the user will never see.
You can use then use
$value = $query->param('hidden_name');
to get the value back from the document after the user clicks on a submit button. You can get more info on this stuff in the perldoc.
| [reply]
[d/l]
[select] |
Re: Game.
by merlyn (Sage) on Jun 04, 2001 at 17:32 UTC
|
| [reply] |
Re: Game.
by pmas (Hermit) on Jun 04, 2001 at 16:23 UTC
|
| [reply] |
|
|
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] |
|
|
|
|
|
|
|
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] |
|
|
|
|
how would I go about using that?
| [reply] |
RTFM
by davorg (Chancellor) on Jun 04, 2001 at 16:33 UTC
|
| [reply] |
Re: Game.
by orkysoft (Friar) on Jun 04, 2001 at 18:20 UTC
|
I used to have a site with a login page, which, when the login was valid, gave out a username cookie and an $ENV{UNIQUE_ID} cookie, which was to avoid putting the password in a cookie.
Probably better is to just give out such an $ENV{UNIQUE_ID} cookie, and, at the server-side, to associate them with a userid and a last-active time to expire it (in case people forget to log out on a public computer!). That way, you can look up their cookie in a table and retrieve all relevant information, if the cookie is (still) valid.
Btw, I think I know who you are. Why don't you create a userid here?
| [reply]
[d/l]
[select] |