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

Howdy!

I have done cookies with Perl before which are accomplished like so:
   $susername = cookie(-name => 'username',
      -value => $userinput,
      -expires => '+10m',
);

[download]

Then before the page starts pass the follow in the header:
print
header(-cookie => [$susername]);

[download]

I used [] around $susername because I usually have more than one scalar being pushed into a cookie.
The Question:
Can a cookie be created without headers? I have a script that takes in a form, and submits into itself. Does some validation on the perl-side (it also has Javascript validation, but that is irrelevant. Then if the validation is a success the script will past them a cookie and redirect them to another page (page two of the form). Is this possible? Can I "pass the user a cookie" without declaring the cookie in the headers. What are my other options besides having to print a "bogus page" with a redirect message and having a cookie created at that point?

I have been thinking about this all weekend, but that last case scenario is the only possible outcome I can think of, and I don't like it. Monks, please help me!

Replies are listed 'Best First'.
Re: CGI Cookies
by hatter (Pilgrim) on Feb 18, 2008 at 14:49 UTC
    Assuming I'm understanding your question, you'd like to avoid the user getting 2 page updates, one to get the cookie, the second to load the second page of the form. Essentially, you can't "do" anything in the browser without it loading a page. The way I tend to handle multipage scripts is to put all the functions into one script, rather than a mix of CGIs to process them and HTML pages served separately.

    In your example, your script called with no parameters would print the first page (either by including the HTML in you script, or by opening a file containing the page or page snippet and printing its contents); the script called with valid form fields prints the second page, including a cookie header; the script called with invalid form fields prints the first page, possibly processed to mark which field was incorrectly filled in, pre-fills any fields the user entered correctly, etc.



    the hatter
[reply]
[d/l]
      Thats what I wanted to confirm was that you cannot pass a cookie without print the page to the browser. I will have to re-think a bit of my logic I think.

      As for putting all of my pages in one script, I dont think that is a good idea. I have about 6 forms that are going to be apart of an application, each form is a different "stage". I want to be able to save to the database after each step. So putting all of my HTML in one hat isn't really an option.

      Thank you for the comments!
[reply]
        Putting all pages in one script might actually be a good idea. As long as you make a hidden parameter in each of your forms with the number of the stage, your script will be able to direct the input to the right routine and you benefit from having all "common" routines in one place, rather than being repeated in all your scripts. Especially the connection to the database will benefit from being only defined once (if you ever have to change anything concerning the database, you make changes in ony one place).

        Also all standard matters, such as headers & footers, CSS, Javascript, Cookies, ... will all be found in one spot.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
        You probably would be best off using a single CGI program to handle all stages. Aside from your original cookie issue, it cuts down on duplicated code (e.g., initialization) by allowing all stages to reference the same routines and also makes it much easier to repeat stages if needed. (User ended up at stage 3, but some of the required information is missing? Just call the stage 2 sub and send them back to fix it.)

        Personally, I tend to use a CGI::Application-style approach to do this, with the code for each different page of the application in a separate module, then a very small .cgi which just loads up those modules and dispatches calls to them based on the request's specified action (CGI::Application calls it a "runmode"). Others are very fond of Catalyst or other frameworks, but I'm not familiar enough with any of them to describe how they function.

        Oh, and I just reread your post and picked up on something I missed earlier... Are you under the impression that "1 CGI script = 1 page"? That is most definitely not the case. The same CGI can produce an unlimited number of distinct pages. Having a single CGI program which produces 6 different pages (selecting based on the input received - or selecting randomly, for that matter) and saving each one's input to the database after each step is no harder (and probably actually easier) than writing 6 separate CGIs which each produce one page.

[reply]

Back to Seekers of Perl Wisdom