FeraliX has asked for the wisdom of the Perl Monks concerning the following question:
2006-05-01 Retitled by g0n, as per Monastery guidelines
Original title: 'Cookies'
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Sending cookies without module
by dynamo (Chaplain) on May 01, 2006 at 04:56 UTC | |
First off, I need to mention that I'm assuming that you mean you want to send an HTTP cookie, you're using Apache as your web server, and you are writing a CGI script (as opposed to using mod_perl, which would require modules to work). Second, you should consider using a module, or at least using some code from inside of them, just to avoid typo trouble. At least, write a function to send the cookie and get it tested before you use it much. Having said that, all you have to do is decide on what your cookie will say (key and value), and in the CGI script, before the "Content-type: text/html\n" line, you will want to print a "Set-Cookie: $Key=$Value\n". I was able to find an example here. Have fun! | [reply] |
|
Re: Sending cookies without module
by jZed (Prior) on May 01, 2006 at 04:54 UTC | |
| [reply] |
|
Re: Sending cookies without module
by Zaxo (Archbishop) on May 01, 2006 at 04:58 UTC | |
. . . without using modules? Why? If you want deep understanding of cookies, that's ok, but Perl without CPAN modules? That's like C without libc. After Compline, | [reply] |
by Anonymous Monk on May 01, 2006 at 05:28 UTC | |
| [reply] [d/l] |
by dynamo (Chaplain) on May 01, 2006 at 07:21 UTC | |
However, if it's printing your headers to the screen, your problem is apparently that your code (/module) has already sent the HTTP headers section _and_the_blank_line_ when it gets to the code above. So you can either stop using the module: or you can tell CGI::Cookie to go ahead and send that header after creating the CGI::Cookie object (see the docs for CGI::Cookie): I didn't use your code in this last example because I'm not sure if you are trying to print the header stuff before all the content, and that's necessary. So make sure this is at the beginning. Then, in CGI::Cookie parlance, you need to bake the cookie: There are many was to write this, check the docs from the link here for more info. | [reply] [d/l] [select] |
by jonadab (Parson) on May 01, 2006 at 11:42 UTC | |
Im attempting a very simple login screen, It's all written and works, It just doesn't remember that they are logged in. I have a login form that on submit reloads the page and loads a subroutine to check if the username/password are correct. Right, there are a couple of number of ways to handle the details, but it boils down to this: you have to remember somewhere not only that the user is logged in, but _who_ they're logged in as. If you put this information in a cookie, and then _trust_ the cookie, anyone will be able to fake being logged in as any user, just by creating a fake cookie (which is easy to do with most browsers), so you don't want to do it that way. You could cryptographically sign the cookie, but that starts to get complicated, and you'd have to verify the signature on every page load. You could put the password into the cookie, but then the password gets passed, in cleartext, with each and every page load, which is not ideal. So the best solution is to store the session information on the _server_ someplace, and just put a unique session-ID number in the cookie that can be used to look up the session information (such as which user is logged in). I usually store the session info in a database, but if you aren't prepared to set up a database you could store it in flat files easily enough, and use the session-ID number as the filename. Then to verify that the user is logged in, you take the session ID number from the cookie that the browser sends you, and you open that file and read the session information (such as the logged-in username) out of it. To create the cookie, you can just do something like this:
However, any script that wants to "remember" later whether the user is logged in or not will need to check the cookie:
Once you get it working, you can decide how long you want to keep the things before expiring them, and create a cron job to clean up the old leftover ones. The storesessioninfo and getsessioninfo routines just need to store and retrieve (respectively) the session information, either in the filesystem, or a database, or in some other way. Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy. | [reply] [d/l] [select] |
by davidrw (Prior) on May 01, 2006 at 13:10 UTC | |
| [reply] |