Using CGI.pm for cookies

Hi,

I've got a problem with setting a cookie. I'm trying to use the CGI.pm module to do so, but for some reason it does not work.

-------------------------------------------------------------------------------
Code :

$cookie1 = cookie(-name=>'user',
-value=>"$user",
-expires=>"$expiration");
$cookie2 = cookie(-name=>'pw',
-value=>"$pw",
-expires=>"$expiration");
print header(-cookie => [$cookie1,$cookie2]);

print<<STOP;
somehtml
STOP
-------------------------------------------------------------------------------

When I try to get my cookies value with cookie(user) I get no value, so I think it did no work.

Thanks for any help.

The syntax for creating new cookie with CGI::Cookie is:

Note the "new" directive in there. It's used to create a new $cookie_name and initialize it with the values you specify.

And then to send it to the browser:


Also, watch that you specify new CGI::Cookie and not new CGI::cookie as it's case sensitive (that gets me a lot)

CGI::Cookie is used internally by CGI.pm for cookies, so if you're already using CGI in your script, you don't need to use CGI::Cookie separately.

Couple of things- DON'T STORE USERNAMES AND PASSWORDS IN COOKIES. This is very, very insecure.

You don't have to put scalars that you pass to methods in quotes, though I doubt that's the problem here.

You have to first set the cookie, and then retrieve it in a separate action. You can't set and retreive a cookie at the same time.

What does your $expires scalar look like?

If your code isn't too long, can you post the whole bit? I don't see anything inherently wrong with what you posted, it may just be a logic problem.

Out of curiosity, what is the alternative to storing a password in a cookie, if you're not using a secure connection or having logins being handled by the browser?

Your alternative is to create a cryptographically secure session id, send that as the value of the cookie, and store user info linked to that session id server-side to match up users later.

When a user comes back to the site, they send the session id in the cookie you set. You have your script look up the session id in your database and get user info from there. Much better than storing username and password info client-side.

I suggest using Digest::MD5's md5_hex() method (don't use md5)base64() because it includes characters that could break a cookie) to hash some random info (like localtime() and some random text) and use that as your session id. These types of ids would be VERY hard to crack, if it's even practically possible.

I'm alreadly using CGI ':standard' so I don't have to use CGI::Cookie anymore, right?

The cookies that are produced at the moment look like that:
-------------------------------------------------------------------------------
user=username; domain=www.mydomain.org; path=/; expires=Saturday, 23-Feb-2002 24:00:00 GMT; secure

pw=password; domain=www.mydomain.org; path=/; expires=Saturday, 23-Feb-2002 24:00:00 GMT; secure
-------------------------------------------------------------------------------

I'm not setting and retrieving the cookie at the same time, so that cannot be the error.

I'm also using a logout function, maybe the mistake is in there, because I once made it to set a cookie but after my logout it did not work anymore.

This is my cookie-delete function:
-------------------------------------------------------------------------------

$cookie_user = new CGI::Cookie(-name => "user",
-value => "$DATA{user}",
-expires=> "Thursday, 01-Jan-1970 00:00:00 GMT",
-domain => "www.mydomain.org",
-path => "/",
-secure => 1);

$cookie_pw = new CGI::Cookie(-name => "pw",
-value => "$DATA{pw}",
-expires=> "Thursday, 01-Jan-1970 00:00:00 GMT",
-domain => "www.mydomain.org",
-path => "/",
-secure => 1);

print header(-cookie=>[$cookie_user,$cookie_pw],
-Refresh=>'3; URL=http://www.mydomain.org/login.pl');
-------------------------------------------------------------------------------

When I try to retrieve the cookie after it shoud be set, I just use cookie(user) to get it, but it worked once, so I think its right.

Nope. Just call the methods for setting/getting cookies like you would any CGI.pm method.

I think the problem might be with your -Refresh in the header. CGI.pm will allow you to send anything you want in an HTTP header, and I don't think that will work as you intend it. If you want to do a redirect with a cookie set/delete, you should either do it like this-



Or, if you really need that three seconds, you can do the cookie delete and use a

in the <head> statement of a page you return with your cookie you delete above.

You can simplify your "expire" thing by just using the shortcuts provided by CGI- for instance, just set the expires to "-1d" (expire yesterday, which deletes the cookie) and let CGI.pm figure out the correct date syntax. If your date syntax is bungled (1970 is awfully early, and it wouldn't surprise me if browsers didn't handle it correctly) you'll probably get strange errors.

One other trick I use is pass basic info along with a redirect. For instance:



I then have my login.pl script look for $q->param('logged_out') on invocation- if it exists, I have my script print a message that says "You have successfully logged out. Thanks!". I actually think this looks more professional, because it avoids the time-wasting "wait three seconds and redirect" stuff. I hate that type of coding. Since when is it user-friendly to make folks wait on purpose?

Please tell me that the %DATA hash isn't a hand-rolled form parser. Given that you're using CGI.pm already, as you should be, you can get your form data with param('parameter_name'), which is one of the best reasons to use CGI.pm in the first place.

And you aren't going to be storing usernames and passwords in cookies, right? This is a terrible idea.

Alright,

thank you very much for you detailed answer ;-)

a) I'm using -location instead of -refresh in my header() now

b) Instead of an exact date I'm using "+1d" and "-1d" in my expiration

c) I like your idea with the logged_out=1 thing and I will use it after I made this cookie thing work, for sure

d) the %DATA hash really came from some parser, but then I found out that the param() method is able to handle "post" and "get" forms and now I'm not using this parser anymore, but I did not want to change the whole variable names ;-)

e) This cookie with the user//password is just a test because I'm trying to build my very first mysql database at the moment, although I'm using PERL for about a year now.


BUT AFTER ALL:

THE COOKIE STILL DOES NOT WORK

Maybe this cookie() function just works with Netscape Navigator, but I cannot image that.

I use CGI.pm to create and manage cookies for a bunch of applications and it works flawlessly everywhere.

Have you deleted the old cookie you must have set during your testing?

Can you post the complete code? I'm sure it's either that you have a stale cookie on your computer, or there's just a fundamental logic error.

I think it might be, that I have a fundamental problem with cookies on my computer, but I'm not sure, because on sites like devshed.com etc. my login is not saved.

My complete code would be much too confusing, I think, but I amost posted the whole think, that regards the cookie.

I just create the cookie with cookie() from CGI.pm and then I try to set it with

print header(-cookie => [$cookie_user,$cookie_pw]);

My logout function just sets the expires to "-1d".

I will try to reinstall my browser, maybe the problem is already solved then ;-)

simple question: how do you use cgi.pm? "use CGI;" ? i must not have this installed on my system.

Read the docs supplied with your distribution of perl, there are plenty of sample scripts there.

You can read them by typing "perldoc CGI" at a command prompt, or online at www.perldoc.com.

It's HIGHLY unlikely that you don't have CGI.pm installed- it's been a standard module since perl4 and up. Search the forum next time, there are plenty of scripts here that use CGI.