http://www.perlmonks.org?node_id=187282

vorteks has asked for the wisdom of the Perl Monks concerning the following question:

Although I've been using Perl for 18 months, I've just started using cookies. I've managed to set a cookie but can't read it back with anything. I've read every thread to try and cure the problem but nothing posted works. Here's the ONLY scripting that works successfuly to set a cookie - everything else gives compilation errors, everything I've tried to read them back does the same too. I'd really appreciate some help with this stupid question as I've been on it for 3 days and read everything going!
#!/usr/bin/perl use CGI qw/:standard/; $user="user1"; $cookie1 = cookie(-name=>'user', -value=>'$user', -expires=>'+1h'); print header(-cookie=>$cookie1);

Replies are listed 'Best First'.
Re: Cookies problem
by sedhed (Scribe) on Aug 03, 2002 at 04:08 UTC

    Hi Vorteks, welcome to the monastery!

    Well, first and foremost, always use strict and warnings. You'd be surprised how many silly typos they catch, as well as making your code cleaner. And, when your CGI's are wonderfully huge applications that need a speed boost, you'll have a much easier time moving to mod_perl.

    Okay, that said, looks like you're setting the cookie okay, but not with any value. Notice your single quotes around the scalar $user when setting the cookie's value. Those quotes are non-interpolative, in other words what you're setting is the string "$user", not the variable's contents. You don't actually need quotes at all in this case.

    Next, I'm going to jump a head a little. Cookies are name/value pairs, and generally you only want to use one cookie on a web page, so as not to be a pain. So it's best to use a hash. You can then pass a reference to your cookie hash to the cookie() function, and thus get more than one hunk of data into a cookie.

    Try some code like this:

    #!/usr/bin/perl use CGI qw/:standard/; use strict; use warnings; #Place the user's existing cookie in a hash, if they have one my %userPrefs = cookie('prefs'); #set the user $userPrefs{user} = 'user1'; # No need to double-quote this string # let's set some timestamps for fun $userPrefs{accessed_last} = $userPrefs{accessed}; $userPrefs{accessed} = scalar localtime; # Now we get a new cookie object my $cookie = cookie( -name => 'prefs', -value => \%userPrefs, -expires => '+1h', ); # and pass it to the browser print header(-cookie=> $cookie); # and let's print the latest cookie info print map {"$_ : $userPrefs{$_}<br>"} sort keys %userPrefs;

    The above code is typed off the cuff, and is untested for typos...

    cheers!

      Absolutely INCREDIBLE!!!! I can't thank you enough, it works a treat!

      Whilst I said I've been using Perl for 18 months, It's on and off at work doing a website for our online tracking system and as you must know, If you leave it a while it's hard to get back into it.
      I have some nasty little habits (no pun intended) and need to get out of them - One of them being to tidy up my coding.
      I decided to use cookies as I was previously using .htaccess and users were having to enter the same user/pass many times whilst moving through various protected folders (this is another problem I could see no answer to).

      Many thanks again for your coding, it's prompted me to open the books again and get learning all the little things I overlooked the last time.

      Best regards

      Tony

        Yes, when working on code in spurts it's always harder to get back into it. My job is half perl, half general system administration, and not split in even halves. :) It's both all day, interrupting programming time with floor calls and hardware problems all day long. It can make remembering where you were a chore...

        Just a side note....You realize of course that just putting a username in a cookie is not at all secure. Anyone can fake a cookie with ease. So it's probably fine for a protected intranet app with trusted users, but if you're trying to keep unauthorized folks out of a public website, that's not going to do it. Your best bet if you need more options than .htaccess files is to look into the Apache::AuthCookie module. I use a subclass of it called Apache::AuthCookieDBI, and though it wasn't all that easy to get going, I love it now.

        cheers!

        I decided to use cookies as I was previously using .htaccess and users were having to enter the same user/pass many times whilst moving through various protected folders (this is another problem I could see no answer to).

        Funny that I was just reading the Apache docs about this earlier today. If you're using Apache, and have the ability to set per-directory .htaccess (which I assume you do), look at: http://httpd.apache.org/docs/howto/auth.html#basicworks You can configure your various secured directories such that they are named under one authentication name, or "realm", to which browsers will send the same auth info on every request. This prevents the constant auth logins when changing directories.

        Try adding the line:
        AuthName "Our Protected Stuff"
        to your .htaccess file and see what happens. I've not tried this, but will soon have a need for it. Let me know how well it works.

        -Shawn
        (Ph) Phaysis
        If idle hands are the tools of the devil, are idol tools the hands of god?

      I feel so dumb for asking the following question but here goes......... When I started learning Perl, most of it was self-taught by looking at scripts and seeing what it does. I suppose that's where my very bad habits come from.
      I am now in the process of reading books from cover to cover to learn the proper way but it all takes time.
      When I wrote the (many and lengthy) scripts, I didn't use my anywhere within them.
      The script that sedhed did for me wroked very well but I've noticed that all the assigned variables after this part of the script are empty. The question:
      Is there a way around this without rewriting all the scripts?
      I will (In time) redo all of them but this is now an urgent issue as my boss is on my back!

      Many thanks for any help or the loan of a .45

        I can't even post a question right so what chance have I got? My apologies.
Cookie transactions
by BorgCopyeditor (Friar) on Aug 03, 2002 at 05:42 UTC

    CGI is, of course, good and all, but sometimes it's nice to know what's going on "under the hood." This can be useful to know if you're in the testing phase and want to be sure your cookie's being read or sent.

    When a page sets a cookie on a browser, all it's doing (usually) is adding this line to its headers:

    Set-Cookie: name=value; expires=(date)

    plus any path you specify. When a cookie-enabled browser requests another page from the domain (or path in that domain specified by the cookie), it adds its own Cookie: header to its request. This is available as $ENV{HTTP_COOKIE}.

    BCE
    --Your punctuation skills are insufficient!

Re: Cookies problem
by dws (Chancellor) on Aug 03, 2002 at 03:46 UTC
    I've managed to set a cookie but can't read it back with anything.

    Try adding -path => '/',