How to send cookie and redirect in a cgi script?

[henry]

if(a)
{
$cookie = $query->cookie(CGISESSID => $session->id );
print $query->header(-cookie=>$cookie);
$session->param("userlevel",$tmp[2]);
$session->param("~logged-in",1);
print $query->redirect('http://x.x.x.x/cgi-bin/check-success');
}
else
{
print $query->redirect('http://x.x.x.x/cgi-bin/fail');

}



I want to do that:if user check success,then send cookie to the user
and redirect to a cgi script.But this program just print the redirect
url to screen.
How can I　implement this ?

thanks!

 

[James Willmore]

if(a)
{
$cookie = $query->cookie(CGISESSID => $session->id );
print $query->header(-cookie=>$cookie);
$session->param("userlevel",$tmp[2]);
$session->param("~logged-in",1);
print $query->redirect('http://x.x.x.x/cgi-bin/check-success');
}
else
{
print $query->redirect('http://x.x.x.x/cgi-bin/fail');

}



I want to do that:if user check success,then send cookie to the user
and redirect to a cgi script.But this program just print the redirect
url to screen.
How can I　implement this ?

Have a look at ...
http://www.stonehenge.com/merlyn/WebTechniques/col61.html

This *may* help you out.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
"Acting is an art which consists of keeping the audience from
<coughing."

 

[Gunnar Hjalmarsson]

I want to do that:if user check success,then send cookie to the
user and redirect to a cgi script.But this program just print the
redirect url to screen.

CGI.pm's header() function returns a trailing blank line, which you
don't want in this case.

Try replacing

print $query->header(-cookie=>$cookie);

with

print "Set-Cookie: $cookie\n";

 

[Alan J. Flavell]

CGI.pm's header() function returns a trailing blank line, which you
don't want in this case.

That's sort-of correct, but it's the wrong emphasis IMHO.

Refer to http://stein.cshl.org/WWW/software/CGI/#header
and scroll down to its the second sub-section
"Creating the Header for a Redirection Request"

The redirect() method is for use INSTEAD of the header() method
when a redirection is desired. Quote:

| All other parameters recognized by the header() method are also
| valid in redirect.

Try replacing

print $query->header(-cookie=>$cookie);

with

print "Set-Cookie: $cookie\n";

Well, you can _try_ it, and if you do it right, it should produce the
desired result. But if you're going to get a cat for pest control,
why continue to catch the mice for yourself?

Use redirect() instead of header(), and include the cookie request
amongst the paramters of the redirect() call.

 

[Gunnar Hjalmarsson]

That's sort-of correct, but it's the wrong emphasis IMHO.

Refer to http://stein.cshl.org/WWW/software/CGI/#header and scroll
down to its the second sub-section "Creating the Header for a
Redirection Request"

Use redirect() instead of header(), and include the cookie request
amongst the paramters of the redirect() call.

Thanks for pointing it out, Alan. That solution is apparently more
along the intentions of the author of CGI.pm than mine.

IMNSHO, this is yet another example of CGI.pm unnecessarily
abstracting trivial things, and it's remarkable, to say the least,
that you're not able to figure it out by help of the 3,400+ lines POD.
Other things than my solution can be said to have the "wrong
emphasis". ;-)

 

[Alan J. Flavell]

IMNSHO, this is yet another example of CGI.pm unnecessarily
abstracting trivial things, and it's remarkable, to say the least,
that you're not able to figure it out by help of the 3,400+ lines POD.

There's a long-standing problem here. The author maintains the CGI.pm
documentation as a rather useful HTML file, which accompanies his
version of the module.

The Perl porters distribute their core version of CGI.pm (just as they
do with other core modules) with POD-format documentation - which then
can be optionally HTML-ified within their installation script.

Unfortunately, these two versions of the documentation are not very
consistent with each other. The POD documentation is quite old, and
tends to lag behind the changes to the code.

Other things than my solution can be said to have the "wrong
emphasis". ;-)

I would definitely recommend to users that they get the author's own
HTML-format documentation for CGI.pm (NOT the HTML-ified POD).
Perhaps the version that corresponds to the version of CGI.pm that
they get to use - or better, if they can, to install a current version
of CGI.pm as a separate module, rather than relying on the version
which happened to come with their core distribution.

While it's true that the HTML documentation has no example shown of
cookie-with-redirect - despite it (apparently[1]) being a frequently
wanted procedure and frequently asked question - nevertheless, it
seems to me that the documentation is set out quite clearly, with
"Creating the HTTP Header" as main section header, and "Creating the
Standard Header for a Virtual Document" and "Creating the Header for a
Redirection Request" as the two sub-section headers, which I think
makes it pretty clear what is wanted here.

all the best

[1] I'm no great fan of cookies myself, and I routinely reject them if
they are offered from a server [browser alert enabled] without any
explanation of any benefits they might bring me as a user.

 

[Gunnar Hjalmarsson]

There's a long-standing problem here. The author maintains the
CGI.pm documentation as a rather useful HTML file, which
accompanies his version of the module.

Since CGI.pm is not just any CPAN module, but included since several
years in the Perl distribution, it's reasonable to expect that its POD
explains the available methods and functions, i.e. that it complies
with perlmodstyle's basic rules for module design. Before your reply
in this thread, I really thought that was the case. I thought that the
other document should be regarded as a user guide.

I still think that's how it should be.

The Perl porters distribute their core version of CGI.pm (just as
they do with other core modules) with POD-format documentation -
which then can be optionally HTML-ified within their installation
script.

Unfortunately, these two versions of the documentation are not very
consistent with each other. The POD documentation is quite old,
and tends to lag behind the changes to the code.

Now you are telling us that the POD is outdated, and that the other
document contains the maintained documentation. Well, if that's the
case, it would be much better IMO - at least short-term - if the POD
was completely dropped and replaced with a note that called the users'
attention to the other document.

As it is now, and if I didn't miss it, the POD does not even include a
reference to the other documentation!