Fresh Out of the Oven

In the interest of saving time and space (the earthly, rather than cosmic, kinds), we can imagine that we've written a similar routine to create the site-prefs cookie. The difference would be that, upon receiving the user's $userid, the subroutine would first query the user_prefs table in the database to harvest the desired preferences.

These preferences would then be stored in the cookie. You could string the preferences together using a delimiter that you'll separate out for later; or, you can store a hash in a cookie. For instance, let's fast forward and imagine that you culled the preferences from user_prefs into a hash named %user_prefs. The hash keys are the field names (matchtype, results_per_page, etc.) and the hash values are the values from the database associated with those fields. You can simply store the entire hash in the cookie:

$cgiobj->cookie(
          -name=>'site-prefs',
          -value=>\%user_prefs,
          -path=>'/'
         );

Later when you retrieve the above cookie, you'll get the hash back, intact, ready-to-eat.

Recall when we attempted to pull the user's account information from user_info. Once the query was performed, an if statement forked the code depending on whether the account record was found or not. Let's go back to that crucial condition.

...

if ($userid) { #login successful
 my $cookie1=&bake_auth_cookie($userid,$username);
 my $cookie2=&bake_prefs_cookie($userid,$username);
 print $cgiobj->header(
         -cookie=>[$cookie1,$cookie2],
	-location=
	 "http://".$cgiobj->server_name.
	 "/login-name.html";
               );
}
else {         #login failed


print $cgiobj->redirect(
 "http://".$cgiobj->server_name."/login-fail.html"
}
...

When the user_info record is found, we bake the two cookies described earlier: the authentication token cookie, saved in $cookie1, and the preferences cookie -- whose subroutine we just imagined -- in $cookie2.

With the two cookies hot and gooey, they're ready to be served. In this case, after we serve the cookies we also want to redirect the user to a home page, login page, or wherever you want them to go once logged in. Because both cookies and page redirection are HTTP header data, we must send both the cookies and the redirection information in a single header() call, as seen in the code above. Once executed, the cookies will be saved by the browser, and the visitor will then be sent to the page specified in the - location parameter. Hopefully that page will be coded to read and act on the cookies, but that's a story for next month!

Finally, a failed login will reach the else clause of this if statement. In this case, we simply redirect the user to a page describing the failed login, probably with another login form so that they can re-attempt, and/or a link to your page where new accounts can be created -- also a topic for another month.

The Aromatic Road Ahead

Next month we'll encounter these cookies as munchers rather than bakers. Using the Embperl module, or embedded Perl, we'll see how easy it is to create web pages that read the cookies and display customized components based on cookie data. In turn, we'll also see how changes to the cookie data -- say, a user changing his or her preferences -- need to be reflected back into the database for long-term storage.

Baking with Julia
The Perl You Need to Know