in reply to Re: How do they expect cookies to work (like this)??
in thread How do they expect cookies to work (like this)??

No. That still doesn't help me SET a cookie after the headers. You just can't call a cookie without setting one and you can't set one after the headers, so how in the world am I supposed to accomplish that? This form has the action ''; meaning it doesn't bring you to a different page, instead it just reloads the one with the form. But with my if/else statements there should be a way to make it all work.

Can someone show me an example on how to setup a snippet like this?

  • Comment on Re: Re: How do they expect cookies to work (like this)??

Replies are listed 'Best First'.
Re: Re: Re: How do they expect cookies to work (like this)??
by antirice (Priest) on Sep 30, 2003 at 18:03 UTC

    Sure, I'll bite:

    #!/usr/bin/perl -w use strict; use CGI qw(header cookie); if (cookie("val")) { print header(),"Your cookie is still set"; } elsif (param("val")) { print header(-cookie=>cookie( -name =>'val', -value=>param("val"), -expires=>'+1M')),"Success! Your cookie should be set"; } else { print header(),q(<html><body><form method="POST" action=""><input ty +pe="text" name="val"><input type="submit" value="Click here"></form>< +/body></html>); }

    Steps: check for the cookie. If present, display still set page. If not, check for a parameter. If present, set the cookie and display success page. If not, display form. I haven't tested the above code, but you should be able to understand what the process entails. I used CGI for all the nasty work. Please click that link and read EVERYTHING. Then check out Ovid's CGI Programming with Perl course.

    Hope this helps.

    antirice    
    The first rule of Perl club is - use Perl
    The
    ith rule of Perl club is - follow rule i - 1 for i > 1

      Thanks antirice, I am sure that's going to work. But I have one more question. What is the elsif doing? I know it's checking for a parameter so do forms (if their action is '') still hace access to everything the user did on the form? I mean, when it redirects back to itself I'll be able to use and play with all the parameters the user used before the page refreshed?

      Thanks!

        Ok. I'm going to introduce you to a very important concept in CGI programming and I truly hope that you consider it very carefully. CGI is stateless.

        Stateless? What in the world do I mean by that? Quite simply: any time your page is accessed, it isn't aware of any other accesses to that page whether they came ten seconds ago or a year ago. Do not think of a person coming to your site and having your script continue to run and somehow magically read across multiple submissions. The script is given certain parameters, such as actual parameters, cookies, environmental variables, etc and it runs based upon the values it was given. That's it. That is the magic of CGI. Now the trick is in making the script cater to different inputs. Also note that the parameters, cookies, environmental variacles, etc may not be the same between submissions. For instance, when someone submits a form, the parameters that are submitted to your script disappear once your script exits (unless you serialize them into a database, a flat file or a cookie). Thus if their cookie is already set when the script is run, the parameters are highly likely to be GONE.

        In the script I provided, it checks for three possible scenarios:

        1. You get a cookie with the name "val".
        2. You get a parameter with the name "val".
        3. You don't get jack.

        In the first case they've presented credentials that say they should pass. At this point, there may be parameters due to them going through the form twice but it doesn't matter because they've already passed. In the second case, they present credentials that say they should pass but we know that they will have no token to prove it in the future unless we magically provide them with something that allows us to check their credentials in the future. Thus we give them these credentials in the form of a cookie so that next time they come in, they will pass. In the third case, we know we can't trust them yet because they haven't proven that they have the required credentials. Thus we ask them for credentials with a form. The thing about this is that at the last two checks, we still offer something to alter the inputs that the browser will give us next time. Should the browser not support forms or cookies, our cgi script will not work because the script knows nothing about the previous submissions due to the fact that the script is stateless.

        By the way, in case you *are* interested in introducing states to CGI, you can emulate a stateful environment by using CGI::Session. It will give the client a sessionid which will identify the session object for later retrieval by your script. Thus you can serialize your parameters into the session object and use it to keep your form values alive.

        Hope this helps.

        antirice    
        The first rule of Perl club is - use Perl
        The
        ith rule of Perl club is - follow rule i - 1 for i > 1

Re: Re: Re: How do they expect cookies to work (like this)??
by perrin (Chancellor) on Sep 30, 2003 at 18:07 UTC
    Which part is confusing you? You have to wait to send the headers until after you add the cookie to them. Look at this example from the CGI.pm documentation.
Re: Re: Re: How do they expect cookies to work (like this)??
by theguvnor (Chaplain) on Sep 30, 2003 at 18:01 UTC

    I believe you're confusing the idea of the script with the concept of page as it applies to the web browser.

    The script generates a page with the form, the form is submitted by the user back to the script which handles the submitted params and generates a page with either success or failure. It is in that "page"'s headers that you set your cookie.

    You basically had the logic right AFAICT in your original post's pseudo-code.

    [Jon]