USING CGI FOR COOKIES
Although the CGI.pm module is huge and you may not wish to learn about all its general features, the CGI::Cookies module is useful for handling cookies - it encapsulates the formatting of the expiry times, for example.
Here's an example of a cgi program which handles cookies on a web page - there are three of them; a short term cookie that lasts for 10 minutes, a long term cookie that lasts for 20 years, and a non-persistant cookie that lasts for the life of the browser.
#!/usr/bin/perl
use CGI::Cookie;
# See what incoming cookies we have!
%cookies = fetch CGI::Cookie();
$ctab = "It is ".time()." i.e. ".localtime()."<BR>\n";
$ctab .= "<table border=1>";
$ctab .= "<tr><td>Name</td><td>Value</td></tr>\n";
foreach $c (keys %cookies) {
$v = $cookies{$c} -> value();
$ctab .= "<tr><td>$c</td><td>$v</td></tr>\n";
}
$ctab .= "</table><BR><BR>";
# Send out any new cookies that we need!
%want = ("short_term" => "+10m", "nonpersistant" => "",
"long_term" => "+240M");
foreach $c (keys %want) {
unless (grep (/^$c$/,keys %cookies)) {
sendcookie($c,time(),$want{$c});
$ctab .= "Set cookie called $c<BR>\n";
} else {
$ctab .= "$c already set<BR>\n";
}
}
print "Content-type: text/html\n\n";
print $ctab;
#############################################################
sub sendcookie {
my ($name,$value,$life) = @_;
my $c;
if ($life) {
$c = new CGI::Cookie(-name => $name,
-expires => $life,
-path => "/",
-value => $value);
} else {
$c = new CGI::Cookie(-name => $name,
-path => "/",
-value => $value);
}
print "Set-Cookie: ",$c->as_string,"\n";
}
This is very much a "teaching example" that doesn't have any real functionallity; it simply collects all the cookies sent back to the script and reports them in a table. If "short_term", "long_term" or "nonpersistant" isn't set, it also sets them.
Note that we've built up the response string in the variable $ctab, and only printed it out after the cookies have been sent as well as the content type. This is necessary since the setting of cookies is done in the heading rather than the body of the HTTP response.
The first time we visit this page, we'll probably get one set of results ....
This shows us that none of our three cookies has been set, but interestingly it does report back a cookie called _uid which has, no doubt, been set by some other script that's running on the same web server and which we've previously run.
Coming back a little later, our results different ....
The short term cookie is no longer set (since more than 10 minutes has elapsed), but the long term and persistant cookies remain, and we have retrieved the values from them from which we can associate this page visit with the previous visit. Here's the information that's saved by our browser in our local cookie file after that second visit:
.yahoo.com TRUE / FALSE 1271361490 B 4oqqragu4cv4i&b=2&f=a
chough FALSE / FALSE 1633359596 _uid whc_1011279594_17808
www.wellho.info FALSE / FALSE 1633367193 _uid whc_1011287306_18780
hc2.humanclick.com FALSE / FALSE 1042808199 HumanClickID 194.117.133.196-124602604
chough FALSE / FALSE 1634726501 long_term 1012646501
chough FALSE / FALSE 1012647817 short_term 1012647217
LEGAL AND SECURITY ISSUES WITH COOKIES
There's currently a legal issue with cookies. It's proposed in European law that web site operators shouldn't be allowed to include information that is stored on the user's machine's permanent storage without asking for permission from the user first.
If this proposed legislation is ratified, we believe that it will mean that you can only set a persistant cookie if you ask the user before you do so - perhaps on a prior form. Persistant cookies are used a great deal on many web sites and this could cause great problems. We hope that it will be sufficient notice to add something on the front page like "This site uses persistant cookies, and if you proceed beyond this point, you are deemed to have accepted that such cookies will be stored on your computer"; we are not legal specialists, however, and suggest you get appropriate advice.
As far as we understand, nonpersistant cookies are not covered by the directive, since they are not stored on your user's hard disk.
Why this legal concern? It's largely a privacy / security issue. Consider:
- With a long persistant cookie, visitors who come to a site and
order in January will be recognised when they come back in July, even if they've just come back because they want to look at a page - they won't be able to visit anonymously.
- With a persistant cookie, anyone who accesses a web page from a
public access terminal that's poorly managed may leave "droppings" behind him, available for subsequent users of that terminal. The better managed internet cafes do have batch files that clear out all the cookies between users, but as a user of such a facility it's hard to know if such scripts actually exist, and the staff on duty when you're there may not be technical enough to know.
See also
Perl on the Web course
Please note that articles in this section of our
web site were current and correct to the best of our ability when published,
but by the nature of our business may go out of date quite quickly. The
quoting of a price, contract term or any other information in this area of
our website is NOT an offer to supply now on those terms - please check
back via
our main web site
Perl - State and Cookies [243] - ()
[1951] - ()
Perl - Using CGI.pm [2231] - ()
resource index - Perl
Solutions centre home page
You'll find shorter technical items at
The Horse's Mouth and
delegate's questions answered at
the
Opentalk forum.
At Well House Consultants, we provide
training courses on
subjects such as Ruby, Lua, Perl, Python, Linux, C, C++,
Tcl/Tk, Tomcat, PHP and MySQL. We're asked (and answer)
many questions, and answers to those which are of general
interest are published in this area of our site.