Re: Get Cookies for Form Input
by Your Mother (Archbishop) on Sep 15, 2010 at 23:28 UTC
|
If I understand correctly: you want the Perl and the PHP to use the same sessions. The good news is what you are trying to do is possible. The bad news is, it won't be super easy for a beginner.
As mentioned, the cookies are in the HTTP headers (not in the HTML at all). So you won't have to put them in pages. You will have to, probably, normalize your Perl to use the PHP session. This should do that for you: PHP::Session.
This isn't hard for an experienced web dev but for a beginner, not so fun. If you can provide a small example of the Perl you need to share the PHP sessions--a working CGI--you'll likely get better help.
| [reply] |
|
| [reply] |
|
I'm sorry but I don't know what to give you. Nothing works.
| [reply] |
|
|
Oh, no. Please not PHP::Session. That was one of the first things I read about. The generic script that gets the cookies and prints them.
#!/usr/bin/perl
use CGI::Carp qw(fatalsToBrowser);
use CGI;
$cgi_query = new CGI;
print $cgi_query->header;
print $cgi_query->start_html('get-cookie.cgi');
print $cgi_query->h4('My cookies are:');
$myCookie1 = $cgi_query->cookie('c1');
$myCookie2 = $cgi_query->cookie('c2');
$myCookie3 = $cgi_query->cookie('c3');
print "<PRE>\n";
print $myCookie1;
print "<br>\n";
print $myCookie2;
print "<br>\n";
print $myCookie3;
print "</PRE>\n";
print $cgi_query->end_html;
I just want them to print in the input box and/or become the value of the form input box. | [reply] [d/l] |
|
To what end? Cookies cannot be used that way. Unless you define your problem better, you are unlikely to get any other help. From your description so far, PHP::Session is exactly what you want and by far the easiest way to get there. Giving a cookie that came from Perl code to PHP will gain you nothing without writing a mess of new and fairly hairy PHP. Second guessing developers who know this stuff is also unlikely to help. :)
| [reply] |
|
Re: Get Cookies for Form Input
by Your Mother (Archbishop) on Sep 16, 2010 at 04:35 UTC
|
This does what you asked for, you might have to adjust the cookie name (currently "sessionID"), and again, it's probably useless.
use warnings;
use strict;
use CGI qw(:standard);
use CGI::Cookie;
my $cookies = CGI::Cookie->fetch;
my $cookie = $cookies->{sessionID} ||
cookie(-name => 'sessionID',
-value => 0,
);
$cookie->value( $cookie->value + 1 );
print
header(-cookie => $cookie),
start_html(),
start_form(),
textfield(-name => "cookie",
-value => $cookie->value),
submit(),
end_form(),
end_html();
Perhaps the Pod for the interface for CGI::Cookie will start to shake some things loose. What it sounds like to me now, from your new description, is that you have a completely insecure set of applications which are passing around customer information in cookie values. This is a huge no-no and I would hope and expect no one here would help you to get it working that way if it's really the case.
Without much more info, and probably lots of sample code, showing how and what the login and sessioning is doing through each app, everything else is just a guessing game.
| [reply] [d/l] |
|
Hi,
Thank you for the script. It worked as it sets a cookie with dynamic content, creates and enters the content into an input box. My goal is to retrieve a pre-existing cookie and use the content as a <TMPL_VAR> tag --in an input box. However, it was very helpful as the $cookies = CGI::Cookie->fetch; when added to the application didn't crash my application script like $cgi_query = new CGI;. I have therefore begun to read he documentation for CGI::Cookie.
I will try/ask around to see if I can modify and convert it to a subroutine to add it to the application.
| [reply] [d/l] [select] |
Re: Get Cookies for Form Input
by Anonymous Monk on Sep 15, 2010 at 23:08 UTC
|
to get the cookie data from the first application and put it into the text input of the second application's login
Cookies are an extra header the browser sends until they expire, they are sent with every HTTP request | [reply] |
Re: Get Cookies for Form Input
by Anonymous Monk on Sep 18, 2010 at 02:26 UTC
|
# /usr/local/bin/perl -w
use CGI::Cookie;
# retrieve the cookie collection
my %cookies = fetch CGI::Cookie;
# retrieve the user_id cookie from the collection
my $user_id = $cookies{"user_id"};
# lookup some user data (e.g. account balance) based on the user's id
my $balance = GetBalance($user_id);
# return the data to the user
print "text/xml\n\n";
print <<EOF;
<vxml version="2.1">
<form>
<block>
<prompt>Your balance is $balance</prompt>
<goto next="main.vxml"/>
</block>
</form>
</vxml>
EOF
# retrieve the user's account balance given their id
sub GetBalance
{
my $user_id = @_;
return "10000.00";
}
Good luck!
| [reply] [d/l] |
|
| [reply] |
Re: Get Cookies for Form Input
by Anonymous Monk on Sep 16, 2010 at 03:44 UTC
|
| [reply] |
|
Depending on the domain names in the applications' URLs the second application may be able to read the contents of the cookie set by the first application.
If the first application runs at http://nonprofit.org/a/ and the second application runs at http://nonprofit.org/b/ then the second application will get the cookie data because the browser will send it via HTTP headers.
If the applications are on different subdomains like a.nonprofit.org and b.nonprofit.org then you may have to update the code that creates the cookie to specify the cookie's domain be nonprofit.org. That will tell the browser to send the cookie data to both applications. Of course then c.nonprofit.org will also get sent a copy of the cookie data when the browser visits it and that may not be desirable for privacy reasons.
Update: ++Your Mother is right about the path. For some more cookie information visit http://www.cookiecentral.com/faq/#3.2
| [reply] [d/l] [select] |
|
This is not necessarily true. If the cookies contain path constraints and they differ, they will not be available to anything on different paths. And I'm not positive, been a long time since I had to do it, but I believe you have to set the domain to .nonprofit.org (leading dot) to make it available to subdomains.
| [reply] |
|
| [reply] |