Re: Cookies, CGI::App, and mod_perl
On Fri, Aug 01, 2003 at 01:14:44PM -0400, Perrin Harkins wrote: On Fri, 2003-08-01 at 13:04, petersm wrote: When running under mod_perl the cookie is no where to be seen. Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. To elaborate a little on this thread: I find ethereal http://www.ethereal.com/ useful for debugging situations like this. Certain browsers (that I won't name) behave in quirky ways that GET or lynx won't emulate, so it's often worth running ethereal in the background whilst using your site with various browsers, then analysing TCP streams in ethereal to see exactly what's happening. Tom
Debugging Tips (Was Re: Cookies, CGI::App, and mod_perl)
Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. To elaborate a little on this thread: I find ethereal http://www.ethereal.com/ useful for debugging situations like this. Certain browsers (that I won't name) behave in quirky ways that GET or lynx won't emulate, so it's often worth running ethereal in the background whilst using your site with various browsers, then analysing TCP streams in ethereal to see exactly what's happening. PlugProxy is also very good for this type of debugging: http://www.bbzzdd.com/plugproxy/ For just examining the HTTP request/response I find it easier and more straighforward to use than Ethereal. (The screen shot on their home page shows an HTTP exchange with hex mode turned on, it's actually much easier to read with hex mode turned off.) A tip for cookie testing when using PlugProxy (or similar proxying tools, I suppose): Generally you need to make sure you're making requests against the correct domain name for your browser to handle the cookies correctly. For example, if you set up PlugProxy on your desktop like so: Host:www.example.org Remote Port: 80 Local Port: then you should be able to use you browser to hit the home page with this: http://localhost:/ *but* the browser won't send the cookies that would normally be sent to example.org. The fix is to make it look like localhost is part of example.org, and then make the request like this instead: http://localhost.example.org:/ You can put something like this: 127.0.0.1 localhost.example.org localhost in /etc/hosts (or WindowsDir\System32\drivers\etc\hosts). Larry Leszczynski [EMAIL PROTECTED]
Re: Cookies, CGI::App, and mod_perl
On Fri, 2003-08-01 at 13:04, petersm wrote: When running under mod_perl the cookie is no where to be seen. Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. If I understand this correctly, then C::A uses CGI to set the cookie and CGI should set it correctly if I'm running under mod_perl right? Right, although I don't think C::A knows or cares at all about cookies. This is just between you and CGI.pm. I've seen a lot on forums to use Apache::Cookie, but how do I do that within C::A? You don't need to use Apache::Cookie, but if you want to you should be able to use it in the normal documented way. C::A should not have any bearing on this. - Perrin
Re: Cookies, CGI::App, and mod_perl
[ Please keep it on the list... ] On Fri, 2003-08-01 at 14:06, petersm wrote: Perrin Harkins [EMAIL PROTECTED] wrote Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. Thanks for the suggestion. I used wget and tried it with the mod_perl stuff in the config and without. Without, wget gave me the header with the cookie. With, wget did not have a cookie in the header. Both returned the correct HTML. Maybe some a glance at my config file could help. So here's the relavant portion. Thanks... PerlModule Apache::StatINC Location /operations/projects/menagerie AddHandler perl-script .cgi PerlHandler Apache::Registry PerlSendHeader On allow from all PerlInitHandler Apache::StatINC PerlSetVar StatINCDebug On PerlSetEnv PERL5LIB /development/operations/projects/ /Location That looks okay to me. Maybe it's something about the way you've structured your code. Try reducing it down to a small snippet that you can post. You may also want to ask on the CGI::Application list. - Perrin
Re: cookies and POST in pure MP2?
Egor Korablev wrote: Hi How can I write and get cookies and get POST data (text) under MP2 handler without using apache::compat? You can either use libapreq, which is _almost_ there :) or hack yuor own bits up cribbed from CGI.pm or the test stuff in the mp2 test suite. That's what I'm using at the moment while assisting as best I can with the libapreq development. If you look through the archives for this list you'll find lots of useful bits pieces. Carl
Re: cookies and POST in pure MP2?
Carl Brewer wrote: Egor Korablev wrote: Hi How can I write and get cookies and get POST data (text) under MP2 handler without using apache::compat? You can either use libapreq, which is _almost_ there :) or hack yuor own bits up cribbed from CGI.pm or the test stuff in the mp2 test suite. That's what I'm using at the moment while assisting as best I can with the libapreq development. If you look through the archives for this list you'll find lots of useful bits pieces. probably you can just use CGI.pm. Carl doesn't want to use it, so he had to go to the pains to extract the wanted bits from it ;) make sure that you are using the latest CGI.pm. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cookies
Forgot to include the list. -Forwarded Message- From: Mark Maunder [EMAIL PROTECTED] To: Dennis Stout [EMAIL PROTECTED] Subject: Re: cookies Date: 16 Jul 2003 14:19:27 -0700 Hi Dennis, One possibility: Check the -path option. It's supposed to set it to '/' by default if you dont specify it, but it doesn't. I discovered this about 20 minutes ago with a similar bug. So manually specify something like: my $cookie = Apache::Cookie-new($r, -name = 'cookiename', -value = 'someval', -expires = '+7d', -domain = '.dontvisitus.org', -path = '/', ); CGI::Cookie works the same in case that's what you're using. If you have Mozilla, go to Preferences/Privacy/Cookies, run cookie manager and check the path that's being set. That's how I discovered this. Hope that helps. Mark. On Wed, 2003-07-16 at 14:13, Dennis Stout wrote: Okay, so technically this isn't really mod_perl speific... but the cookie is being set with mod_perl and it's a huge mod_perl program being affected by this:) I have a cookie, the domain is set to .stout.dyndns.org (with the leading .). I set the cookie just fine now (thanks to those helping me on thatr) I had a problem parsing the cookie. Added some debugging (okay, warn lines up the yingyang) and after cycling through the headers and warning them out to the errorlog... I never saw any cookie info. So... If the website is ttms.stout.dyndns.org shouldn't the cookie domain be .stout.dyndns.org? *sigh* 6 more days to finish this database. I doubt I'll make it. Dennis -- Mark Maunder [EMAIL PROTECTED] ZipTree Inc. -- Mark Maunder [EMAIL PROTECTED] ZipTree Inc.
Re: cookies
One possibility: Check the -path option. It's supposed to set it to '/'
by default if you dont specify it, but it doesn't. I discovered this
about 20 minutes ago with a similar bug. So manually specify something
like:
my $cookie = Apache::Cookie-new($r,
-name = 'cookiename',
-value = 'someval',
-expires = '+7d',
-domain = '.dontvisitus.org',
-path = '/',
);
what I have is this:
sub set_auth_cookie {
my $state = shift;
my $val = build_auth_string($state);
my $c = Apache::Cookie-new($state-{r},
-name = 'ttms_user',
-value = $val,
-expires= time + 86400*30*7,
-domain = $Cookie_Domain,
-path = '/',
);
$state-{cookie_out} = $c;
}
This is called by various other routines, and $state is a hash = {r = $r, q =
\%q }, where q is a hash = {$r-args, $r-content}.
build_auth_string is another subroutine that makes a 446bit encryption string
thats encoded with mime::base64...
I got a path. Does that get sent to all webpages ever, or just ones underh te
/ directory? In otherwords, does hte cookie get sent when accessing
/login.html and not when accessing /admin/view_techs.html?
All the pages on this domain are generated dynamically with a custom built
dispatch table and some awesome subroutinage. Does that matter? Maybe I
should read the complete netscape cookie specification :/
I know the cookie is set because it tells me when it expires and when it was
last accessed and what not on the box I browse to it with. (win2k... blah)
And the program itself is running in a Linux environment :)
Time for more warnage in the routines...
If anyone wants sourcecode to look at, email me. It's much to big to just
post to the list.
Dennis
Re: cookies
Well I'll be damned. My computer at home does the cookie thing perfectly well. My workstation at work does not do cookies. So my mod_perl creation is working fine as far as getting the cookies. rant YAY FOR WIN2K DOMAINS AND ADMIN WHO USE HELP DESK TECHS TO PROGRAM TICKETING SYSTEMS FOR DSL, DIGITAL TV, AND DOMAINS! /rant I still have a problem tho. The cookie string itself is not being passed along. Instead, I am getting Apache::Cookie=SCALAR(0x9115c24). I imagine somewhere I need to do something like -as_string or something. blah Thanks for helping, sorry I didn't spot that the error was infact, in the dumbterminal called a win2k box I was using, and not in any actual code Dennis Stout - Original Message - From: Dennis Stout [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 13 13 Subject: cookies Okay, so technically this isn't really mod_perl speific... but the cookie is being set with mod_perl and it's a huge mod_perl program being affected by this:) I have a cookie, the domain is set to .stout.dyndns.org (with the leading .). I set the cookie just fine now (thanks to those helping me on thatr) I had a problem parsing the cookie. Added some debugging (okay, warn lines up the yingyang) and after cycling through the headers and warning them out to the errorlog... I never saw any cookie info. So... If the website is ttms.stout.dyndns.org shouldn't the cookie domain be .stout.dyndns.org? *sigh* 6 more days to finish this database. I doubt I'll make it. Dennis
Re: cookies
*pounds head against brick wall* why must it work against me???
A cookie for anyone who solves this.
sub handler {
my $r = shift;
my $result = undef;
eval { $result = inner_handler($r) };
return $result unless $@;
warn Uncaught Exception: $@;
return SERVER_ERROR;
}
sub inner_handler {
my $r = shift;
my %q = ($r-args, $r-content);
my %state = (r = $r, q = \%q);
$state{title} = '';
$state{template} = '';
$state{auth_status} = password_boxes(\%state);
# warn %ENV: \n;
# foreach (keys %ENV) {
# warn $_ = $ENV{$_}\n;
# }
# my %headers = $r-headers_in;
# warn Headers: \n;
# foreach (keys %headers) {
# warn $_: $headers{$_}\n;
# }
my $cookie = Apache::Cookie-fetch;
warn z - $cookie-value;
validate_auth_cookie(\%state, $cookie);
my $function = $r-uri;
if (($state{login_user} eq '') and ($function ne '/login.cgi')) {
$function = '/login.html';
}
my $func = $Dispatch{$function} || $Dispatch{DEFAULT};
return DECLINED unless $func;
return $func-(\%state);
}
Upon accessing a page (therefore generating lots of warning info in logs...) I
get this in my error log.
z - HASH(0x916ea08)-value at /home/httpd/ttms/perl/RequestHandler.pm line
108.
(the z is there so I know where at in my code the line in the log file is
being generated. I like z's and a's more than I do
some/long/path/and/filename line 108)
I have tried using $cookie as a value in and of itself, I've tried
$cookie-{ttms_user} (the name of hte cookie is ttms_user), I've tried
changing $cookie to %cookie and doing a $cookie{ttms_user} ..
I might break down, declare this a bug, and use $ENV{HTTP_COOKIE} instead.
Any ideas how to fix this to return to me the cookie itself? Thanks.
Dennis
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: Dennis Stout [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 20 13
Subject: Re: cookies
Well I'll be damned.
My computer at home does the cookie thing perfectly well. My workstation at
work does not do cookies. So my mod_perl creation is working fine as far as
getting the cookies.
rant
YAY FOR WIN2K DOMAINS AND ADMIN WHO USE HELP DESK TECHS TO PROGRAM TICKETING
SYSTEMS FOR DSL, DIGITAL TV, AND DOMAINS!
/rant
I still have a problem tho. The cookie string itself is not being passed
along. Instead, I am getting Apache::Cookie=SCALAR(0x9115c24).
I imagine somewhere I need to do something like -as_string or something.
blah
Thanks for helping, sorry I didn't spot that the error was infact, in the
dumbterminal called a win2k box I was using, and not in any actual code
Dennis Stout
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 13 13
Subject: cookies
Okay, so technically this isn't really mod_perl speific... but the
cookie
is being set with mod_perl and it's a huge mod_perl program being affected
by
this:)
I have a cookie, the domain is set to .stout.dyndns.org (with the leading
.).
I set the cookie just fine now (thanks to those helping me on thatr)
I had a problem parsing the cookie. Added some debugging (okay, warn
lines
up
the yingyang) and after cycling through the headers and warning them out
to
the errorlog... I never saw any cookie info.
So... If the website is ttms.stout.dyndns.org shouldn't the cookie domain
be
.stout.dyndns.org?
*sigh* 6 more days to finish this database. I doubt I'll make it.
Dennis
Re: cookies
From perldoc CGI::Cookie
# fetch existing cookies
%cookies = fetch CGI::Cookie;
$id = $cookies{'ID'}-value;
#You're doing $cookies-value;
ID == the name that you used when you set the cookie.
On Wed, 2003-07-16 at 21:27, Dennis Stout wrote:
*pounds head against brick wall* why must it work against me???
A cookie for anyone who solves this.
sub handler {
my $r = shift;
my $result = undef;
eval { $result = inner_handler($r) };
return $result unless $@;
warn Uncaught Exception: $@;
return SERVER_ERROR;
}
sub inner_handler {
my $r = shift;
my %q = ($r-args, $r-content);
my %state = (r = $r, q = \%q);
$state{title} = '';
$state{template} = '';
$state{auth_status} = password_boxes(\%state);
# warn %ENV: \n;
# foreach (keys %ENV) {
# warn $_ = $ENV{$_}\n;
# }
# my %headers = $r-headers_in;
# warn Headers: \n;
# foreach (keys %headers) {
# warn $_: $headers{$_}\n;
# }
my $cookie = Apache::Cookie-fetch;
warn z - $cookie-value;
validate_auth_cookie(\%state, $cookie);
my $function = $r-uri;
if (($state{login_user} eq '') and ($function ne '/login.cgi')) {
$function = '/login.html';
}
my $func = $Dispatch{$function} || $Dispatch{DEFAULT};
return DECLINED unless $func;
return $func-(\%state);
}
Upon accessing a page (therefore generating lots of warning info in logs...) I
get this in my error log.
z - HASH(0x916ea08)-value at /home/httpd/ttms/perl/RequestHandler.pm line
108.
(the z is there so I know where at in my code the line in the log file is
being generated. I like z's and a's more than I do
some/long/path/and/filename line 108)
I have tried using $cookie as a value in and of itself, I've tried
$cookie-{ttms_user} (the name of hte cookie is ttms_user), I've tried
changing $cookie to %cookie and doing a $cookie{ttms_user} ..
I might break down, declare this a bug, and use $ENV{HTTP_COOKIE} instead.
Any ideas how to fix this to return to me the cookie itself? Thanks.
Dennis
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: Dennis Stout [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 20 13
Subject: Re: cookies
Well I'll be damned.
My computer at home does the cookie thing perfectly well. My workstation at
work does not do cookies. So my mod_perl creation is working fine as far as
getting the cookies.
rant
YAY FOR WIN2K DOMAINS AND ADMIN WHO USE HELP DESK TECHS TO PROGRAM TICKETING
SYSTEMS FOR DSL, DIGITAL TV, AND DOMAINS!
/rant
I still have a problem tho. The cookie string itself is not being passed
along. Instead, I am getting Apache::Cookie=SCALAR(0x9115c24).
I imagine somewhere I need to do something like -as_string or something.
blah
Thanks for helping, sorry I didn't spot that the error was infact, in the
dumbterminal called a win2k box I was using, and not in any actual code
Dennis Stout
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 13 13
Subject: cookies
Okay, so technically this isn't really mod_perl speific... but the
cookie
is being set with mod_perl and it's a huge mod_perl program being affected
by
this:)
I have a cookie, the domain is set to .stout.dyndns.org (with the leading
.).
I set the cookie just fine now (thanks to those helping me on thatr)
I had a problem parsing the cookie. Added some debugging (okay, warn
lines
up
the yingyang) and after cycling through the headers and warning them out
to
the errorlog... I never saw any cookie info.
So... If the website is ttms.stout.dyndns.org shouldn't the cookie domain
be
.stout.dyndns.org?
*sigh* 6 more days to finish this database. I doubt I'll make it.
Dennis
--
Mark Maunder [EMAIL PROTECTED]
ZipTree Inc.
Re: cookies
w00t!
ttms_user: mp2Ti5p1JkhCObm9LKBFGsiAltop8aAWwl6vLLDr/3rtb09MRzZrEg==
Here,
your $cookie = Apache::Cookie-new($state-{r},
-name = 'Mark',
-value = 'AWESOME!!!',
-expires= time + 86400*30*7,
-domain = '.dyndns.org',
-path = '/',
);
(okay, I made up your, it sounds better than my, and sinec this is fake
nayways... heh)
oop, looking at that, I should set the domain to something more sane again,
like stout.dyndns.org. :P
Dennis
P.S. Does anyone else try to use Outlook Express like vi and get odd error
messages after a days worth of coding?
- Original Message -
From: Mark Maunder [EMAIL PROTECTED]
To: Dennis Stout [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 20 33
Subject: Re: cookies
From perldoc CGI::Cookie
# fetch existing cookies
%cookies = fetch CGI::Cookie;
$id = $cookies{'ID'}-value;
#You're doing $cookies-value;
ID == the name that you used when you set the cookie.
On Wed, 2003-07-16 at 21:27, Dennis Stout wrote:
*pounds head against brick wall* why must it work against me???
A cookie for anyone who solves this.
sub handler {
my $r = shift;
my $result = undef;
eval { $result = inner_handler($r) };
return $result unless $@;
warn Uncaught Exception: $@;
return SERVER_ERROR;
}
sub inner_handler {
my $r = shift;
my %q = ($r-args, $r-content);
my %state = (r = $r, q = \%q);
$state{title} = '';
$state{template} = '';
$state{auth_status} = password_boxes(\%state);
# warn %ENV: \n;
# foreach (keys %ENV) {
# warn $_ = $ENV{$_}\n;
# }
# my %headers = $r-headers_in;
# warn Headers: \n;
# foreach (keys %headers) {
# warn $_: $headers{$_}\n;
# }
my $cookie = Apache::Cookie-fetch;
warn z - $cookie-value;
validate_auth_cookie(\%state, $cookie);
my $function = $r-uri;
if (($state{login_user} eq '') and ($function ne '/login.cgi')) {
$function = '/login.html';
}
my $func = $Dispatch{$function} || $Dispatch{DEFAULT};
return DECLINED unless $func;
return $func-(\%state);
}
Upon accessing a page (therefore generating lots of warning info in
logs...) I
get this in my error log.
z - HASH(0x916ea08)-value at /home/httpd/ttms/perl/RequestHandler.pm line
108.
(the z is there so I know where at in my code the line in the log file is
being generated. I like z's and a's more than I do
some/long/path/and/filename line 108)
I have tried using $cookie as a value in and of itself, I've tried
$cookie-{ttms_user} (the name of hte cookie is ttms_user), I've tried
changing $cookie to %cookie and doing a $cookie{ttms_user} ..
I might break down, declare this a bug, and use $ENV{HTTP_COOKIE} instead.
Any ideas how to fix this to return to me the cookie itself? Thanks.
Dennis
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: Dennis Stout [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 20 13
Subject: Re: cookies
Well I'll be damned.
My computer at home does the cookie thing perfectly well. My
workstation at
work does not do cookies. So my mod_perl creation is working fine as
far as
getting the cookies.
rant
YAY FOR WIN2K DOMAINS AND ADMIN WHO USE HELP DESK TECHS TO PROGRAM
TICKETING
SYSTEMS FOR DSL, DIGITAL TV, AND DOMAINS!
/rant
I still have a problem tho. The cookie string itself is not being
passed
along. Instead, I am getting Apache::Cookie=SCALAR(0x9115c24).
I imagine somewhere I need to do something like -as_string or
something.
blah
Thanks for helping, sorry I didn't spot that the error was infact, in
the
dumbterminal called a win2k box I was using, and not in any actual
code
Dennis Stout
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 13 13
Subject: cookies
Okay, so technically this isn't really mod_perl speific... but the
cookie
is being set with mod_perl and it's a huge mod_perl program being
affected
by
this:)
I have a cookie, the domain is set to .stout.dyndns.org (with the
leading
.).
I set the cookie just fine now (thanks to those helping me on thatr)
I had a problem parsing the cookie. Added some debugging (okay, warn
lines
up
the yingyang) and after cycling through the headers and warning them
out
to
the errorlog... I never saw any cookie info.
So... If the website is ttms.stout.dyndns.org shouldn't the cookie
domain
be
.stout.dyndns.org
Re: cookies
Cool dude. Now if you know why $r-pnotes() isn't working under
apache/modperl .27 you'll make my day!
:wq
On Wed, 2003-07-16 at 21:42, Dennis Stout wrote:
w00t!
ttms_user: mp2Ti5p1JkhCObm9LKBFGsiAltop8aAWwl6vLLDr/3rtb09MRzZrEg==
Here,
your $cookie = Apache::Cookie-new($state-{r},
-name = 'Mark',
-value = 'AWESOME!!!',
-expires= time + 86400*30*7,
-domain = '.dyndns.org',
-path = '/',
);
(okay, I made up your, it sounds better than my, and sinec this is fake
nayways... heh)
oop, looking at that, I should set the domain to something more sane again,
like stout.dyndns.org. :P
Dennis
P.S. Does anyone else try to use Outlook Express like vi and get odd error
messages after a days worth of coding?
- Original Message -
From: Mark Maunder [EMAIL PROTECTED]
To: Dennis Stout [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 20 33
Subject: Re: cookies
From perldoc CGI::Cookie
# fetch existing cookies
%cookies = fetch CGI::Cookie;
$id = $cookies{'ID'}-value;
#You're doing $cookies-value;
ID == the name that you used when you set the cookie.
On Wed, 2003-07-16 at 21:27, Dennis Stout wrote:
*pounds head against brick wall* why must it work against me???
A cookie for anyone who solves this.
sub handler {
my $r = shift;
my $result = undef;
eval { $result = inner_handler($r) };
return $result unless $@;
warn Uncaught Exception: $@;
return SERVER_ERROR;
}
sub inner_handler {
my $r = shift;
my %q = ($r-args, $r-content);
my %state = (r = $r, q = \%q);
$state{title} = '';
$state{template} = '';
$state{auth_status} = password_boxes(\%state);
# warn %ENV: \n;
# foreach (keys %ENV) {
# warn $_ = $ENV{$_}\n;
# }
# my %headers = $r-headers_in;
# warn Headers: \n;
# foreach (keys %headers) {
# warn $_: $headers{$_}\n;
# }
my $cookie = Apache::Cookie-fetch;
warn z - $cookie-value;
validate_auth_cookie(\%state, $cookie);
my $function = $r-uri;
if (($state{login_user} eq '') and ($function ne '/login.cgi')) {
$function = '/login.html';
}
my $func = $Dispatch{$function} || $Dispatch{DEFAULT};
return DECLINED unless $func;
return $func-(\%state);
}
Upon accessing a page (therefore generating lots of warning info in
logs...) I
get this in my error log.
z - HASH(0x916ea08)-value at /home/httpd/ttms/perl/RequestHandler.pm line
108.
(the z is there so I know where at in my code the line in the log file is
being generated. I like z's and a's more than I do
some/long/path/and/filename line 108)
I have tried using $cookie as a value in and of itself, I've tried
$cookie-{ttms_user} (the name of hte cookie is ttms_user), I've tried
changing $cookie to %cookie and doing a $cookie{ttms_user} ..
I might break down, declare this a bug, and use $ENV{HTTP_COOKIE} instead.
Any ideas how to fix this to return to me the cookie itself? Thanks.
Dennis
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: Dennis Stout [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 20 13
Subject: Re: cookies
Well I'll be damned.
My computer at home does the cookie thing perfectly well. My
workstation at
work does not do cookies. So my mod_perl creation is working fine as
far as
getting the cookies.
rant
YAY FOR WIN2K DOMAINS AND ADMIN WHO USE HELP DESK TECHS TO PROGRAM
TICKETING
SYSTEMS FOR DSL, DIGITAL TV, AND DOMAINS!
/rant
I still have a problem tho. The cookie string itself is not being
passed
along. Instead, I am getting Apache::Cookie=SCALAR(0x9115c24).
I imagine somewhere I need to do something like -as_string or
something.
blah
Thanks for helping, sorry I didn't spot that the error was infact, in
the
dumbterminal called a win2k box I was using, and not in any actual
code
Dennis Stout
- Original Message -
From: Dennis Stout [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2003 13 13
Subject: cookies
Okay, so technically this isn't really mod_perl speific... but the
cookie
is being set with mod_perl and it's a huge mod_perl program being
affected
by
this:)
I have a cookie, the domain is set to .stout.dyndns.org (with the
leading
.).
I set the cookie just fine now (thanks to those helping me on thatr)
I
Re: cookies
Cool dude. Now if you know why $r-pnotes() isn't working under apache/modperl .27 you'll make my day! Got some source code to show me what you're doing with it? Otherwise I'll just have to cut and paste the mod_perl API book to you ;) hehehehe. Dennis
Re: cookies
WOOO! I went to the ttms site, logged in, AND IT AUTHNTICATED ME AND GAVE ME PAGES!! :D Aight, drink of choice is on me tonight :D I can't beleive it! 3 weeks on this bloody thing and I got it to finally Authenticat me =D Course, I had to disable things in order to get it to give me a cookie to authenticate with, but a few if's will fix that :D I'm happy, I'm happy, I'm happy! I might actually meet deadline :D w00t! er... *ahem* My thanks to all of you, and special thanks to Mark who helped me the most :D Dennis
Re: cookies and IE
Wouldn't be the first time I've been wrong. I do know that I was seeing inconsistent behavior with cookies not being saved in a redirect page (mostly IE PC, but not 100% of the time), but I didn't spend any time worrying about it because of the previous messages I remembered. A quick check of my mailbox shows a discussion back in March where someone suggested using Refresh instead of Redirect to get around the problem. I recall previous discussions, but I don't have any on file. Actually, I had the same problem with certain versions of IE not setting cookies when they are used with redirects... I ended up making it so that the redirect was unnecessary. After a while I switched to HTTP authentication - In many ways it's even simpler :-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: cookies and IE
On Tue, Oct 01, 2002 at 07:23:39PM -0400, Kee Hinckley wrote: At 11:30 AM -0700 10/1/02, Alan wrote: Hi folks... I'm having a bit of a weird problem with Apache::Cookie and IE. I'm setting a cookie and then doing a redirect as follows: This must come up once every few months. I'd complain about that fact, but the irony is that just last week I couldn't figure out why a new site I was working on wasn't setting cookies in IE and I'd done the same thing I'd read about a dozen times. IE doesn't reliably set cookies on a refresh. I believe the only solution is to rearchitect the site. Interesting... on the several browsers/OSs I had it tested on it seemed to work. Anyway, if this is such a common question, who do you talk to to get it stuck in the perl.apache.org page about cookies? :) alan -- Alan Arcterex [EMAIL PROTECTED] -=][=- http://arcterex.net I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I think I preferred the cows. They were better conversation, easier to milk, and if they annoyed me enough, I could shoot them and eat them. -Rodger Donaldson
Re: cookies and IE
Hi Alan,
I guess your mistake is to send the refresh header as http header.
You should use a meta tag in html or redirect in http.
Sven.
On Tue, 1 Oct 2002, Alan wrote:
Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
IE.
I'm setting a cookie and then doing a redirect as follows:
my $c = Apache::Cookie-new( $r,
-name = 'userdata',
-value = $cookie,
-expires = '1d',
-path = '/dealers'
);
$r-content_type('text/html');
$c-bake;
$r-header_out(Refresh=0;url=/dealers$request_uri);
$r-no_cache(1);
$r-send_http_header;
$r-print( print_refresh_page_content() );
(print_refresh_page_content() just returns a string of authenticated)
After the authenticated message is printed it should refresh back to the
/dealers/ URL, except this time the handler will see there is a cookie
and print out the real data, not a username/pass prompt.
This works *perfectly* in mozilla linux, galeon, mozilla windows, and
ie6 under windows XP. It *doesn't* work on ie 6 under win98, winME, or
ie 5.5 run through crossover office. It displays the authenticated
page, but then refreshes back to the login page. No cookie is set, but
debug when setting the cookie shows the following:
Set-Cookie=userdata=[data]; path=/dealers; expires=1d at
/home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Refresh=0;url=/dealers/ at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm
line 139.
Pragma=no-cache at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
Cache-control=no-cache at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm
line 139.
Connection=close at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line
139.
Content-Type=text/html at /home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm
line 139.
Expires=Tue, 01 Oct 2002 18:30:31 GMT at
/home/alan/code/rubberoven/mod_perl/Rubberoven/Dealer.pm line 139.
This is the same that is printed out when a working browser gets cookies
set.
I've played around with the security settings, and even at the lowest
setting, with IE set to prompt for any cookies, it won't even
acknowledge that I'm trying to set a cookie.
Anyone have any ideas/solutions/thoughts?
--
Sven Geislere-mail: [EMAIL PROTECTED]
Senior Developertel:(+49 30) 53 62 16 27
Re: cookies and IE
At 09:02 02.10.2002, Alan wrote: On Tue, Oct 01, 2002 at 07:23:39PM -0400, Kee Hinckley wrote: At 11:30 AM -0700 10/1/02, Alan wrote: Hi folks... I'm having a bit of a weird problem with Apache::Cookie and IE. I'm setting a cookie and then doing a redirect as follows: This must come up once every few months. I'd complain about that fact, but the irony is that just last week I couldn't figure out why a new site I was working on wasn't setting cookies in IE and I'd done the same thing I'd read about a dozen times. IE doesn't reliably set cookies on a refresh. I believe the only solution is to rearchitect the site. Interesting... on the several browsers/OSs I had it tested on it seemed to work. Anyway, if this is such a common question, who do you talk to to get it stuck in the perl.apache.org page about cookies? :) Send some paragraphs detailing this to me (preferably in POD), and it'll be added to the site. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: cookies and IE
Alan wrote [ 01 October 2002 at 03:09 pm ] On Tue, Oct 01, 2002 at 11:30:59AM -0700, Alan wrote: Turns out the issue was the 'expires' tag... IE wouldn't set the cookie until it was set to '+1d' If setting the expires tag to +1d fixed the problem you may want to look at the time on the machine running IE. I ran into a problem where the clients clock was in the wrong timezone, this of course changed the distance from GMT and caused the cookie to be expired as it was sent. IE did not accept the cookie at all. However once the time was set correctly the cookie worked correctly. -- nicholas l studt [EMAIL PROTECTED]
Re: cookies and IE
On Wed, Oct 02, 2002 at 08:15:23AM -0500, Nicholas Studt wrote: Alan wrote [ 01 October 2002 at 03:09 pm ] On Tue, Oct 01, 2002 at 11:30:59AM -0700, Alan wrote: Turns out the issue was the 'expires' tag... IE wouldn't set the cookie until it was set to '+1d' If setting the expires tag to +1d fixed the problem you may want to look at the time on the machine running IE. I ran into a problem where the clients clock was in the wrong timezone, this of course changed the distance from GMT and caused the cookie to be expired as it was sent. IE did not accept the cookie at all. However once the time was set correctly the cookie worked correctly. Nope... one of the versions of IE that I was running was on the same machine (running through crossover office). Looks like my little problem really had nothing to do with refreshing and setting cookies, but it was actually in the way that parsing works in Apache::Cookie (and CGI/CGI::Cookie). When the expires is set to +3d the cookie is set as follows: Set-Cookie=name=value; path=/path; expires=Sat, 05-Oct-2002 15:10:06 GMT But when it's set to 3d the cookie is set as: Set-Cookie=name=value; path=/path; expires=3d Which makes sense, but it's a very subtle thing IMHO, and to me 1d means expire in one day, the same as +1d. Anything think that this deserves a bug report, or chalk it up to stupid user syndrome? Alan -- Alan Arcterex [EMAIL PROTECTED] -=][=- http://arcterex.net I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I think I preferred the cows. They were better conversation, easier to milk, and if they annoyed me enough, I could shoot them and eat them. -Rodger Donaldson
Re: cookies and IE
But when it's set to 3d the cookie is set as: Set-Cookie=name=value; path=/path; expires=3d Which makes sense, but it's a very subtle thing IMHO, and to me 1d means expire in one day, the same as +1d. Anything think that this deserves a bug report, or chalk it up to stupid user syndrome? the logic in apache_request.c seems to indicate that you get options +time, -time, and 'now'. any other formats (such as 1d) get the literal string in the cookie. untested, though :) the Apache::Cookie manpage says it's a CGI::Cookie emulation, where CGI::Cookie says to see CGI.pm for acceptable -expires values, which doesn't say much except illustrate that + and - and 'now' are permissible values. so, it's not really a bug if you dig down into the docs and examples. looks like a feature, though :) I can't think of a reason why you'd want a literal in the expires field, but I don't use cookies all that much, so maybe there are some cases where it's desirable. maybe $cookie should be undef, or the cookie should default to browser-session-only if -expires doesn't follow the standard format? maybe that's a question for [EMAIL PROTECTED] --Geoff
Re: cookies and IE
On Wed, Oct 02, 2002 at 01:21:49PM -0400, Geoffrey Young wrote: so, it's not really a bug if you dig down into the docs and examples. looks like a feature, though :) Agreed... more of a 'gotcha' though, ready to bite people in the butt. Personally I think it might make more sense to do a check to see if the val =~ /(\d+)(h|m|d|M)/ before it's sent off as a literal, but who knows. I'll email someone about it anyway. alan -- Alan Arcterex [EMAIL PROTECTED] -=][=- http://arcterex.net I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I think I preferred the cows. They were better conversation, easier to milk, and if they annoyed me enough, I could shoot them and eat them. -Rodger Donaldson
Re: cookies and IE
At 20:12 02.10.2002, Alan wrote: On Wed, Oct 02, 2002 at 01:21:49PM -0400, Geoffrey Young wrote: so, it's not really a bug if you dig down into the docs and examples. looks like a feature, though :) Agreed... more of a 'gotcha' though, ready to bite people in the butt. Personally I think it might make more sense to do a check to see if the val =~ /(\d+)(h|m|d|M)/ before it's sent off as a literal, but who knows. I'll email someone about it anyway. It's because you can put a correctly formatted date string in the -expires option, AFAIK. So if using your idea, the literal string might be misinterpreted. Also, don't forget that you have +1d and -1d as another possibility. I think the +/- makes sense. It's just one character :) -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: cookies and IE
On Wed, Oct 02, 2002 at 08:30:54PM +0200, Per Einar Ellefsen wrote: At 20:12 02.10.2002, Alan wrote: On Wed, Oct 02, 2002 at 01:21:49PM -0400, Geoffrey Young wrote: so, it's not really a bug if you dig down into the docs and examples. looks like a feature, though :) Agreed... more of a 'gotcha' though, ready to bite people in the butt. Personally I think it might make more sense to do a check to see if the val =~ /(\d+)(h|m|d|M)/ before it's sent off as a literal, but who knows. I'll email someone about it anyway. It's because you can put a correctly formatted date string in the -expires option, AFAIK. So if using your idea, the literal string might be misinterpreted. Also, don't forget that you have +1d and -1d as another possibility. I think the +/- makes sense. It's just one character :) Oh, totally agreed, I just figured that it might be a good way to set a default if there was no + or -, which could eliminate headaches for people like me :) Also, as there's no chance of a correctly formatted date string being \d(h|m|d|etc), it could be a fair assumption. My $0.02 anyway! :) alan -- Alan Arcterex [EMAIL PROTECTED] -=][=- http://arcterex.net I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I think I preferred the cows. They were better conversation, easier to milk, and if they annoyed me enough, I could shoot them and eat them. -Rodger Donaldson
Re: cookies and IE
At 9:29 AM +0200 10/2/02, Sven Geisler wrote: Hi Alan, Hi Kee, I would say Kee is wrong. In our application, the development of which I am involved in, for a special case we need to write a cookie and redirect to another page. Wouldn't be the first time I've been wrong. I do know that I was seeing inconsistent behavior with cookies not being saved in a redirect page (mostly IE PC, but not 100% of the time), but I didn't spend any time worrying about it because of the previous messages I remembered. A quick check of my mailbox shows a discussion back in March where someone suggested using Refresh instead of Redirect to get around the problem. I recall previous discussions, but I don't have any on file. The typical case here is that the user goes to page a, you redirect them to page b for authentication, they submit their password and the password page then sets a cookie and sends them back to a. It may be that the problem was a coding one rather than a browser one. I just tore out the code and instead decided to internally display page b without doing a a redirect. So your URL is for a, but the content is the login page (b). On submit page sees a successful login, sets the cookie, and displays itself. EmpberlObject made this trivial to do, and it ended up meaning less server roundtrips and less code. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: cookies and IE
On Tue, Oct 01, 2002 at 11:30:59AM -0700, Alan wrote:
Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
IE.
I'm setting a cookie and then doing a redirect as follows:
my $c = Apache::Cookie-new( $r,
-name = 'userdata',
-value = $cookie,
-expires = '1d',
-path = '/dealers'
);
$r-content_type('text/html');
$c-bake;
$r-header_out(Refresh=0;url=/dealers$request_uri);
$r-no_cache(1);
$r-send_http_header;
$r-print( print_refresh_page_content() );
Turns out the issue was the 'expires' tag... IE wouldn't set the cookie
until it was set to '+1d'
alan
--
Alan Arcterex [EMAIL PROTECTED] -=][=- http://arcterex.net
I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I
think I preferred the cows. They were better conversation, easier to milk, and
if they annoyed me enough, I could shoot them and eat them. -Rodger Donaldson
Re: cookies and IE
At 11:30 AM -0700 10/1/02, Alan wrote: Hi folks... I'm having a bit of a weird problem with Apache::Cookie and IE. I'm setting a cookie and then doing a redirect as follows: This must come up once every few months. I'd complain about that fact, but the irony is that just last week I couldn't figure out why a new site I was working on wasn't setting cookies in IE and I'd done the same thing I'd read about a dozen times. IE doesn't reliably set cookies on a refresh. I believe the only solution is to rearchitect the site. -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
RE: Cookies and IE in mod_perl
I've determined that it isn't the redirect causing the cookies not to be set. If I take out the redirect, and just try to set a cookie w/o a redirect, it still doesn't set the cookies in IE. Does M$ have any docs on how IE6 handles cookies that I can look this up on? YES, they do. You have to setup the Privacy Policy, which means you have to have a P3P header coming out of your webserver with each request. You'll want to lookup the details and docs, and PLEASE customize for your own website, but... *I* fixed this by adding this to my httpd.conf (and I got it from this mailing list anyway :-): # P3P Policy (required for IE6 to accept our cookies) Header add P3P CP=\NOI DSP COR CURa PSDa OUR NOR NAV STA\ This requires mod_headers to be loaded or compiled into Apache. Good luck! L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Re: Cookies and IE in mod_perl
I've determined that it isn't the redirect causing the cookies not to be set.
If I take out the redirect, and just try to set a cookie w/o a redirect, it
still doesn't set the cookies in IE. Does M$ have any docs on how IE6
handles cookies that I can look this up on?
On Saturday 23 March 2002 11:48 pm, Cees Hek wrote:
Some browsers don't accept cookies sent allong with a redirect header.
A simple workaround is to leave your cookie in the header, but move the
redirect to a META HTTP-EQUIV tag in a blank HTML document.
I'm not sure if IE 6.0 suffers from this but I suspect that this is your
problem. So this isn't really a mod_perl problem, but likely a browser
problem.
Also, if you want to see exactly what headers your apache server is
sending out, or headers your client is sending in, have a look at
Apache::DumpHeaders. It saves putting those warn statements in your
code.
Cees
On Sun, 2002-03-24 at 14:44, Jesse and Rebecca Stay wrote:
Ok - I got rid of the Apache::Cookie stuff, and am now doing things
manually, but it still doesn't generate a cookie in IE. It still works
in Netscape. I get a redirect, but no cookie. Here is my code:
my $r = Apache-request;
$r-content_type('text/html');
$r-err_headers_out-add('Set-Cookie' = 'userSession=test;
domain=.hainesfamily.org; path=/; expires=Mon, 25-Mar-2002 03:30:43
GMT'); $r-headers_out-add(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
my $headers_out = $r-headers_out;
foreach (keys %$headers_out) {
warn $_=$headers_out-{$_};
}
return OK;
The warn produces the following:
Set-Cookie=userSession=test; domain=.domain.org; path=/; expires=Mon,
25-Mar-2002 03:30:43 GMT at /path/to/script.pm line 326.
Location=/r/common/loginWelcome at /path/to/script.pm line 326.
Connection=close at /path/to/script.pm line 326.
Transfer-Encoding=chunked at /path/to/script.pm line 326.
Content-Type=text/html at /path/to/script.pm line 326.
Am I doing something wrong???
-Jesse Stay
On Saturday 23 March 2002 06:43 pm, Eric Frazier wrote:
Strong suggestion. Look at an existing cookie that works in IE
whatever, copy it, then look at the header that Apache::Cookie is
making. This oop cookie crap really bugs me since a cookie is just a
stupid header line, not that big of a deal to parse, or write by hand.
Abscraction is for things that make good objects and that are HARD,
cookies in my opinon don't fit into that category.
I strongly bet it has to do with the expire date, also look at the
docs, and the code itself under the expires sub. I haven't done e com
crap for a while now, but I had lots of trouble getting IE to get it
right. Remember Netscape invented the cookie, then IE had to go and
tweak with it.
Eric
At 09:21 PM 3/23/02 -0500, Jesse and Rebecca Stay wrote:
I guess in particular, does anyone know of any known issues with
Apache::Cookie and IE6.0 (or any other versions)?
On Saturday 23 March 2002 07:09 pm, Jesse and Rebecca Stay wrote:
Here is the code I use (in this particular case it is being used
with a redirect, but it doesn't work in any case.):
my $cookieContent = Apache::Cookie-new(
$r,
-name= 'userSession',
-value = $cookieValue,
-expires = '+365d');
$cookieContent-bake();
$r-headers_out-set(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
I tried expires = '+1Y', but that didn't work either. Adding the
domain doesn't do anything either.
On Saturday 23 March 2002 06:44 pm, Frank Wiles wrote:
On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay
[EMAIL PROTECTED] wrote:
Has anyone had any issues in getting cookies to work with IE
using mod_perl? I have tried using both CGI::Cookie and
Apache::Cookie, and in both instances it works just fine under
Netscape, but on IE it doesn't even try to set the cookie. Any
ideas?
What are you expire times on your cookies? We ran into a
situation where I work that all of the Windows machines were in
the wrong time zone and with a 2 hour expire, IE would not set the
cookie because it thought it was already expired. Netscape would
however set the cookie anyway.
This may not be your problem, but it may be something to think
about.
-
Frank Wiles [EMAIL PROTECTED]
http://frank.wiles.org
-
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Re: Cookies and IE in mod_perl
On Sat, 23 Mar 2002, Jesse and Rebecca Stay wrote:
Ok - I got rid of the Apache::Cookie stuff, and am now doing things manually,
but it still doesn't generate a cookie in IE. It still works in Netscape. I
get a redirect, but no cookie. Here is my code:
my $r = Apache-request;
$r-content_type('text/html');
$r-err_headers_out-add('Set-Cookie' = 'userSession=test;
domain=.hainesfamily.org; path=/; expires=Mon, 25-Mar-2002 03:30:43 GMT');
$r-headers_out-add(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
my $headers_out = $r-headers_out;
foreach (keys %$headers_out) {
warn $_=$headers_out-{$_};
}
return OK;
I think this should be
return 302;
Re: Cookies and IE in mod_perl
On Sun, Mar 24, 2002 at 01:44:51PM -0500, Jesse and Rebecca Stay wrote: I've determined that it isn't the redirect causing the cookies not to be set. If I take out the redirect, and just try to set a cookie w/o a redirect, it still doesn't set the cookies in IE. Does M$ have any docs on how IE6 handles cookies that I can look this up on? http://www.microsoft.com/presspass/press/2001/mar01/PrivacyToolsIEfs.asp Balazs
Fw: Re: Cookies and IE in mod_perl
On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay [EMAIL PROTECTED] wrote: Has anyone had any issues in getting cookies to work with IE using mod_perl? I have tried using both CGI::Cookie and Apache::Cookie, and in both instances it works just fine under Netscape, but on IE it doesn't even try to set the cookie. Any ideas? What are you expire times on your cookies? We ran into a situation where I work that all of the Windows machines were in the wrong time zone and with a 2 hour expire, IE would not set the cookie because it thought it was already expired. Netscape would however set the cookie anyway. This may not be your problem, but it may be something to think about. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
Re: Cookies and IE in mod_perl
Here is the code I use (in this particular case it is being used with a redirect, but it doesn't work in any case.): my $cookieContent = Apache::Cookie-new( $r, -name= 'userSession', -value = $cookieValue, -expires = '+365d'); $cookieContent-bake(); $r-headers_out-set(Location = $redir); $r-status(REDIRECT); $r-send_http_header; return OK; I tried expires = '+1Y', but that didn't work either. Adding the domain doesn't do anything either. On Saturday 23 March 2002 06:44 pm, Frank Wiles wrote: On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay [EMAIL PROTECTED] wrote: Has anyone had any issues in getting cookies to work with IE using mod_perl? I have tried using both CGI::Cookie and Apache::Cookie, and in both instances it works just fine under Netscape, but on IE it doesn't even try to set the cookie. Any ideas? What are you expire times on your cookies? We ran into a situation where I work that all of the Windows machines were in the wrong time zone and with a 2 hour expire, IE would not set the cookie because it thought it was already expired. Netscape would however set the cookie anyway. This may not be your problem, but it may be something to think about. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
Re: Cookies and IE in mod_perl
I guess in particular, does anyone know of any known issues with Apache::Cookie and IE6.0 (or any other versions)? On Saturday 23 March 2002 07:09 pm, Jesse and Rebecca Stay wrote: Here is the code I use (in this particular case it is being used with a redirect, but it doesn't work in any case.): my $cookieContent = Apache::Cookie-new( $r, -name= 'userSession', -value = $cookieValue, -expires = '+365d'); $cookieContent-bake(); $r-headers_out-set(Location = $redir); $r-status(REDIRECT); $r-send_http_header; return OK; I tried expires = '+1Y', but that didn't work either. Adding the domain doesn't do anything either. On Saturday 23 March 2002 06:44 pm, Frank Wiles wrote: On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay [EMAIL PROTECTED] wrote: Has anyone had any issues in getting cookies to work with IE using mod_perl? I have tried using both CGI::Cookie and Apache::Cookie, and in both instances it works just fine under Netscape, but on IE it doesn't even try to set the cookie. Any ideas? What are you expire times on your cookies? We ran into a situation where I work that all of the Windows machines were in the wrong time zone and with a 2 hour expire, IE would not set the cookie because it thought it was already expired. Netscape would however set the cookie anyway. This may not be your problem, but it may be something to think about. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
Re: Cookies and IE in mod_perl
Ok - I got rid of the Apache::Cookie stuff, and am now doing things manually,
but it still doesn't generate a cookie in IE. It still works in Netscape. I
get a redirect, but no cookie. Here is my code:
my $r = Apache-request;
$r-content_type('text/html');
$r-err_headers_out-add('Set-Cookie' = 'userSession=test;
domain=.hainesfamily.org; path=/; expires=Mon, 25-Mar-2002 03:30:43 GMT');
$r-headers_out-add(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
my $headers_out = $r-headers_out;
foreach (keys %$headers_out) {
warn $_=$headers_out-{$_};
}
return OK;
The warn produces the following:
Set-Cookie=userSession=test; domain=.domain.org; path=/; expires=Mon,
25-Mar-2002 03:30:43 GMT at /path/to/script.pm line 326.
Location=/r/common/loginWelcome at /path/to/script.pm line 326.
Connection=close at /path/to/script.pm line 326.
Transfer-Encoding=chunked at /path/to/script.pm line 326.
Content-Type=text/html at /path/to/script.pm line 326.
Am I doing something wrong???
-Jesse Stay
On Saturday 23 March 2002 06:43 pm, Eric Frazier wrote:
Strong suggestion. Look at an existing cookie that works in IE whatever,
copy it, then look at the header that Apache::Cookie is making.
This oop cookie crap really bugs me since a cookie is just a stupid header
line, not that big of a deal to parse, or write by hand.
Abscraction is for things that make good objects and that are HARD, cookies
in my opinon don't fit into that category.
I strongly bet it has to do with the expire date, also look at the docs,
and the code itself under the expires sub. I haven't done e com crap for a
while now, but I had lots of trouble getting IE to get it right. Remember
Netscape invented the cookie, then IE had to go and tweak with it.
Eric
At 09:21 PM 3/23/02 -0500, Jesse and Rebecca Stay wrote:
I guess in particular, does anyone know of any known issues with
Apache::Cookie and IE6.0 (or any other versions)?
On Saturday 23 March 2002 07:09 pm, Jesse and Rebecca Stay wrote:
Here is the code I use (in this particular case it is being used with a
redirect, but it doesn't work in any case.):
my $cookieContent = Apache::Cookie-new(
$r,
-name= 'userSession',
-value = $cookieValue,
-expires = '+365d');
$cookieContent-bake();
$r-headers_out-set(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
I tried expires = '+1Y', but that didn't work either. Adding the
domain doesn't do anything either.
On Saturday 23 March 2002 06:44 pm, Frank Wiles wrote:
On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay
[EMAIL PROTECTED] wrote:
Has anyone had any issues in getting cookies to work with IE using
mod_perl? I have tried using both CGI::Cookie and Apache::Cookie,
and in both instances it works just fine under Netscape, but on IE
it doesn't even try to set the cookie. Any ideas?
What are you expire times on your cookies? We ran into a situation
where I work that all of the Windows machines were in the wrong time
zone and with a 2 hour expire, IE would not set the cookie because it
thought it was already expired. Netscape would however set the cookie
anyway.
This may not be your problem, but it may be something to think
about.
-
Frank Wiles [EMAIL PROTECTED]
http://frank.wiles.org
-
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Re: Fw: Re: Cookies and IE in mod_perl
There are different security levels that must be set. You can also specifically tell the browser to accept all cookies from a particular domain. There is an article on MS site about this. I forgot what it was. You can probably search for it on google. Frank Wiles wrote: [EMAIL PROTECTED]"> On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay [EMAIL PROTECTED] wrote: Has anyone had any issues in getting cookies to work with IE using mod_perl? I have tried using both CGI::Cookie and Apache::Cookie, and in both instances it works just fine under Netscape, but on IE it doesn't even try to set the cookie. Any ideas? What are you expire times on your cookies? We ran into a situation where I work that all of the Windows machines were in the wrong time zoneand with a 2 hour expire, IE would not set the cookie because it thought it was already expired. Netscape would however set the cookie anyway.This may not be your problem, but it may be something to think about. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
Re: Cookies and IE in mod_perl
Some browsers don't accept cookies sent allong with a redirect header.
A simple workaround is to leave your cookie in the header, but move the
redirect to a META HTTP-EQUIV tag in a blank HTML document.
I'm not sure if IE 6.0 suffers from this but I suspect that this is your
problem. So this isn't really a mod_perl problem, but likely a browser
problem.
Also, if you want to see exactly what headers your apache server is
sending out, or headers your client is sending in, have a look at
Apache::DumpHeaders. It saves putting those warn statements in your
code.
Cees
On Sun, 2002-03-24 at 14:44, Jesse and Rebecca Stay wrote:
Ok - I got rid of the Apache::Cookie stuff, and am now doing things manually,
but it still doesn't generate a cookie in IE. It still works in Netscape. I
get a redirect, but no cookie. Here is my code:
my $r = Apache-request;
$r-content_type('text/html');
$r-err_headers_out-add('Set-Cookie' = 'userSession=test;
domain=.hainesfamily.org; path=/; expires=Mon, 25-Mar-2002 03:30:43 GMT');
$r-headers_out-add(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
my $headers_out = $r-headers_out;
foreach (keys %$headers_out) {
warn $_=$headers_out-{$_};
}
return OK;
The warn produces the following:
Set-Cookie=userSession=test; domain=.domain.org; path=/; expires=Mon,
25-Mar-2002 03:30:43 GMT at /path/to/script.pm line 326.
Location=/r/common/loginWelcome at /path/to/script.pm line 326.
Connection=close at /path/to/script.pm line 326.
Transfer-Encoding=chunked at /path/to/script.pm line 326.
Content-Type=text/html at /path/to/script.pm line 326.
Am I doing something wrong???
-Jesse Stay
On Saturday 23 March 2002 06:43 pm, Eric Frazier wrote:
Strong suggestion. Look at an existing cookie that works in IE whatever,
copy it, then look at the header that Apache::Cookie is making.
This oop cookie crap really bugs me since a cookie is just a stupid header
line, not that big of a deal to parse, or write by hand.
Abscraction is for things that make good objects and that are HARD, cookies
in my opinon don't fit into that category.
I strongly bet it has to do with the expire date, also look at the docs,
and the code itself under the expires sub. I haven't done e com crap for a
while now, but I had lots of trouble getting IE to get it right. Remember
Netscape invented the cookie, then IE had to go and tweak with it.
Eric
At 09:21 PM 3/23/02 -0500, Jesse and Rebecca Stay wrote:
I guess in particular, does anyone know of any known issues with
Apache::Cookie and IE6.0 (or any other versions)?
On Saturday 23 March 2002 07:09 pm, Jesse and Rebecca Stay wrote:
Here is the code I use (in this particular case it is being used with a
redirect, but it doesn't work in any case.):
my $cookieContent = Apache::Cookie-new(
$r,
-name= 'userSession',
-value = $cookieValue,
-expires = '+365d');
$cookieContent-bake();
$r-headers_out-set(Location = $redir);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
I tried expires = '+1Y', but that didn't work either. Adding the
domain doesn't do anything either.
On Saturday 23 March 2002 06:44 pm, Frank Wiles wrote:
On Sat, 23 Mar 2002 18:52:14 -0500 Jesse and Rebecca Stay
[EMAIL PROTECTED] wrote:
Has anyone had any issues in getting cookies to work with IE using
mod_perl? I have tried using both CGI::Cookie and Apache::Cookie,
and in both instances it works just fine under Netscape, but on IE
it doesn't even try to set the cookie. Any ideas?
What are you expire times on your cookies? We ran into a situation
where I work that all of the Windows machines were in the wrong time
zone and with a 2 hour expire, IE would not set the cookie because it
thought it was already expired. Netscape would however set the cookie
anyway.
This may not be your problem, but it may be something to think
about.
-
Frank Wiles [EMAIL PROTECTED]
http://frank.wiles.org
-
http://www.kwinternet.com/eric
(250) 655 - 9513 (PST Time Zone)
Re: Cookies and redirects
On Tue, 12 Mar 2002 16:23:57 +0100 Axel Andersson [EMAIL PROTECTED] wrote: Hello, I'm having trouble with both setting a cookie and redirecting the user to another page at the same time. It would appear the cookie is only sent when a normal header is sent by server. If I do the following (having baked the cookie first), where $r is the Apache-request() object: $r-content_type(text/html; charset=iso-8859-1); $r-send_http_header(); Hi, a common trick to solve this is to use err_header_out() request method. For example: use Apache::Constants qw(:common); $r-err_header_out(Set-Cookie = $my_cookie ); $r-custom_response(SERVER_ERROR, $my_custom_redir_location); return SERVER_ERROR; Bye Enrico = Enrico Sorcinelli - Gruppo E-Comm - Italia On Line S.p.a. E-Mail: [EMAIL PROTECTED] - [EMAIL PROTECTED] =
Re: Cookies and redirects
Axel Andersson wrote: Hello, I'm having trouble with both setting a cookie and redirecting the user to another page at the same time. It would appear the cookie is only sent when a normal header is sent by server. this is a common problem - you have to add the cookie to the err_headers_out table instead of the headers_out table. if you are using Apache::Cookie then this is done for you, otherwise you have to populate the correct set of headers. see http://perl.apache.org/guide/snippets.html#Sending_Cookies_in_REDIRECT_Resp or Recipes 3.7 and 3.13 in the mod_perl cookbook --Geoff
Re: Cookies and redirects
Geoff: I think I did this with my own module with no success... I'd end up with an extra set of headers, if I was _lucky_... perhaps that is due to a general misunderstanding of err_headers_out - they are sent _even_ on Apache errors (of which REDIRECT is considered one), not _only_ on errors. so, if you were setting headers_out to capture normal transactions and err_headers_out for errors, you might get an extra set of headers if you were not careful in your own coding methodology. Also, when I got it to redirect OK, even when I saw the cookie, sometimes the browser would not eat the cookie properly... I don't have more specific details, because this was months ago and the project was not (then) under CVS control (now it is, of course)... well, details are good :) this sounds like a browser issue, though - if you populate the err_headers_out table with a cookie it will be presented to the client on a REDIRECT response. nevertheless, Axel emailed me privately saying that err_headers_out() solved his issues. --Geoff
Re: Cookies and redirects
El Mar 12 Mar 2002 11:23, Axel Andersson escribió:
Hello,
I'm having trouble with both setting a cookie and redirecting the user to
another page at the same time. It would appear the cookie is only sent
when a normal header is sent by server.
If I do the following (having baked the cookie first), where $r is the
Apache-request() object:
$r-content_type(text/html; charset=iso-8859-1);
$r-send_http_header();
I get this header:
Connection: close
Date: Tue, 12 Mar 2002 10:39:05 GMT
Server: Apache/1.3.23 (Unix) mod_perl/1.26
Content-Type: text/html; charset=iso-8859-1
Client-Date: Tue, 12 Mar 2002 10:39:05 GMT
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Set-Cookie: user=12::7c786c222596437b; domain=animanga.nu; path=/;
expires=Wed,
12-Mar-2003 10:39:05 GMT
Very nice and all, with cookie set. However, doing:
$r-method_number(M_GET);
$r-method(GET);
$r-headers_in-unset(Content-length);
$r-headers_out-add(Location = /users.pl);
$r-status(REDIRECT);
$r-send_http_header();
Which I gather is the normal way to redirect a user, I get this header:
Connection: close
Date: Tue, 12 Mar 2002 10:38:36 GMT
Server: Apache/1.3.23 (Unix) mod_perl/1.26
Content-Type: text/html; charset=iso-8859-1
Client-Date: Tue, 12 Mar 2002 10:38:36 GMT
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Right, no Set-cookie there. So what's up? How do I redirect a browser,
and set a cookie at the same time?
Thanks in advance,
Axel Andersson
Have you tried printing the headers_out hashref after sending the http header
to see if the cookie is there ?.
my $headers_out = $r-headers_out;
foreach (keys %$headers_out) {
warn $_=$headers_out-{$_};
}
Hans
Re: Cookies and Handlers
Time abbreviations are case sensitive:
=pod
The following forms are all valid for the -expires field:
+30s 30 seconds from now
+10m ten minutes from now
+1h one hour from now
-1d yesterday (i.e. ASAP!)
now immediately
+3M in three months
+10y in ten years time
=cut
So, change +24H to +24h.
Note that you may also, $u-bake() since you're using Apache::Cookie. This
will set the outgoing headers for you.
Regards,
Tim Tompkins
--
Programmer
http://www.arttoday.com/
http://www.rebelartist.com/
--
- Original Message -
From: Rasoul Hajikhani [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, August 08, 2001 6:11 PM
Subject: Cookies and Handlers
Why is setting cookies so complex in mod_perl...
Can any one tell me how I can set a few cookies in one handler and hand
over the operation to another handler to do some more stuff...
I have tried everything that I know (that's not much) but I still can
not set the cookies...
here is the snippet of my cookie setter handler:
my $u = Apache::Cookie-new( $r,
-name = 'randh_webuname',
-value = $webuname,
-domain = '.rhythm.com',
-expires= '+24H',
-path = '/'
);
$r-err_headers_out-add('Set-Cookie' = $u) if $u;
some more cookies here
$r-err_headers_out;
return DECLINED; # tried OK with the same result
}
1;
At this point my second handler takes over ...
.
.
.
$r-err_headers_out;
return OK;
Please Help :(
-r
Re: Cookies and redirection
Glen Small [EMAIL PROTECTED] said something to this effect on 06/26/2001: I'm having some problem setting a cookie in a logon script i have. The code work fine as a CGI, and also under mod)perl, however, I want to set a cookie during the login script, and then redirect the browser to another page. http://perl.apache.org/guide/snippets.html#Sending_Cookies_in_REDIRECT_Resp -- The kind of thinking we do sets the stage for the action we are likely to take. Because of this, a man who refuses to develop his thinking is likely to act on the impressions made upon him by others. -- Dr. Claude R. Baker, Coin In The Air
Re: cookies work for some browsers, not for others... ?
will trillich([EMAIL PROTECTED])@Sat, Apr 28, 2001 at 02:44:29PM -0500: i've been tinkering with the modperl book examples for Apache::Ticket*.pm (as described p305-322)... it works for linux/konqueror linux/netscape win/explorer it doesn't work for linux/lynx mac/netscape Dude you forgot excellent links browser - text mode and support for tables frames! pavel
Re: cookies work for some browsers, not for others... ?
- Original Message - From: will trillich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 28, 2001 9:44 PM Subject: cookies work for some browsers, not for others... ? [snip] cf !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sample-from-modperl-book.com/login;here/A.P /BODY/HTML 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? That's the formatting done for the chunked content-type. I really don't recall exactly how it works. All I remember is that each set of hexadecimal digits [that's what they are] somehow must represent the next chunk to be transferred - it might be a byte count. In any case, if you're REALLY interested, go look it up in the RFC for HTTP/1.1 - it's explained in better detail there. [snip] HTTP/1.1 200 OK Date: Sat, 28 Apr 2001 19:27:34 GMT Server: Apache/1.3.9 Transfer-Encoding: chunked Content-Type: text/html 294 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN HTMLHEADTITLELog In/TITLE /HEADBODY BGCOLOR=whiteH1Please Log In/H1FORM METHOD=POST ACTION=/login ENCTYPE=application/x-www-form-urlencoded TABLETRTDName/TD TDINPUT TYPE=text NAME=user /TD/TR TRTDPassword/TD TDINPUT TYPE=password NAME=password /TD/TR/TABLEINPUT TYPE=hidden NAME=request_uri VALUE=http://sample-from-modperl-book.com/try?;INPUT TYPE=submit NAME=Log In VALUE=Log InP/FORMEMNote: /EMYou must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with 294 in front, and 0 again taking up the rear. what's up with that? ??? See above. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: cookies work for some browsers, not for others... ?
- Original Message - From: will trillich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 28, 2001 9:44 PM Subject: cookies work for some browsers, not for others... ? [snip] cf !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE302 Found/TITLE /HEADBODY H1Found/H1 The document has moved A HREF=http://www.sample-from-modperl-book.com/login;here/A.P /BODY/HTML 0 Connection closed by foreign host. ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? That's the formatting done for the chunked content-type. I really don't recall exactly how it works. All I remember is that each set of hexadecimal digits [that's what they are] somehow must represent the next chunk to be transferred - it might be a byte count. In any case, if you're REALLY interested, go look it up in the RFC for HTTP/1.1 - it's explained in better detail there. [snip] HTTP/1.1 200 OK Date: Sat, 28 Apr 2001 19:27:34 GMT Server: Apache/1.3.9 Transfer-Encoding: chunked Content-Type: text/html 294 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN HTMLHEADTITLELog In/TITLE /HEADBODY BGCOLOR=whiteH1Please Log In/H1FORM METHOD=POST ACTION=/login ENCTYPE=application/x-www-form-urlencoded TABLETRTDName/TD TDINPUT TYPE=text NAME=user /TD/TR TRTDPassword/TD TDINPUT TYPE=password NAME=password /TD/TR/TABLEINPUT TYPE=hidden NAME=request_uri VALUE=http://sample-from-modperl-book.com/try?;INPUT TYPE=submit NAME=Log In VALUE=Log InP/FORMEMNote: /EMYou must set your browser to accept cookies in order for login to succeed.You will be asked to log in again after some period of time has elapsed. 0 Connection closed by foreign host. ??? and here it's bracketed with 294 in front, and 0 again taking up the rear. what's up with that? ??? See above. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: cookies work for some browsers, not for others... ?
in general, your problem with some browsers that otherwise support cookies may be with issuing redirects and cookies on the same request, which has been known to trip up some browsers. the easy workaround is to use a meta refresh to do the redirection. fmt: w70: No such file or directory On Sat, Apr 28, 2001 at 02:44:29PM -0500, will trillich wrote: ??? what's that trailing zero for (or from), by the way? and that cf that preceeds !DOCTYPE... ? ??? chunked encoding. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 jim
Re: cookies work for some browsers, not for others... ?
On Sat, Apr 28, 2001 at 12:54:17PM -0700, Jim Winstead wrote: in general, your problem with some browsers that otherwise support cookies may be with issuing redirects and cookies on the same request, which has been known to trip up some browsers. the easy workaround is to use a meta refresh to do the redirection. pooh. i'll look into that. hmm. they all do the redirect properly, but when they arrive at the redirected url, they don't seem to have (or at least report) the cookies they've been given. so i guess what you're saying is, some browsers look for a redirect: header and then charge off to the new location without handling any set-cookie: headers in the meantime? fmt: w70: No such file or directory hmm? -- [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: cookies work for some browsers, not for others... ?
At 17:17 28/04/2001 -0500, will trillich wrote: so i guess what you're saying is, some browsers look for a redirect: header and then charge off to the new location without handling any set-cookie: headers in the meantime? Precisely. And some also don't report the cookie before the second page after the redirect (presumably because they consider it to be the same request). I think that behaviour only happens with permanent redirects though. One thing that helps (often, not always) is to make sure that your Set-Cookie header is sent before the Location header of the redirect. ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Many people would sooner die than think. In fact, they do. - Bertrand Russell
Re: cookies work for some browsers, not for others... ?
On Sun, Apr 29, 2001 at 12:21:33AM +0200, Robin Berjon wrote:
At 17:17 28/04/2001 -0500, will trillich wrote:
so i guess what you're saying is, some browsers look for
a redirect: header and then charge off to the new location
without handling any set-cookie: headers in the meantime?
Precisely. And some also don't report the cookie before the second page
after the redirect (presumably because they consider it to be the same
request). I think that behaviour only happens with permanent redirects though.
One thing that helps (often, not always) is to make sure that your
Set-Cookie header is sent before the Location header of the redirect.
here's the code, direct from the modperl book, and downloaded in
person from modperl.com:
package Apache::TicketAccess;
use strict;
use Apache::Constants qw(:common);
use Apache::TicketTool ();
sub handler {
my $r = shift;
my $ticketTool = Apache::TicketTool-new($r);
my($result, $msg) = $ticketTool-verify_ticket($r);
unless ($result) {
$r-log_reason($msg, $r-filename);
my $cookie = $ticketTool-make_return_address($r);
$r-err_headers_out-add('Set-Cookie' = $cookie);
return FORBIDDEN;
}
return OK;
}
1;
__END__
i suppose i'd need to change
return FORBIDDEN;
to
print htmlheaders-including-meta-refresh, brief-html-stuff;
return OK;
right?
--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
RE: Cookies in PerlAccessHandlers
You may have a typo in the code provided. Also, you should probably start
using mod_perl methods rather than perl built-in functions.
In a PerlAccessHandler I have code similar to the following:
sub handler
{
my $r = shift;
my ($cgi, $cookie);
use CGI;
$cgi = new CGI;
$cookie = $cgi-cookie(-name = 'test');
# For debugging only
open(TEST, /tmp/accesstest);
flock(TEST,2);
print TEST cookie = $cookie;
close(test);
This should certainly be something like:
my $log = $r-log();
$log-debug(cookie = $cookie);
which would log to the apache error log (with LogLevel set to debug in
httpd.conf). Did you mean to close TEST instead of test?
# This if block is not included in the PerlHandler version
if ($cookie eq '')
{
return FORBIDDEN;
}
Still need to return something here!
return OK;
}
However, nothing is written to the log file and the forbidden
screen is
displayed. The exact same code works fine if its in a regular
mod_perl module
installed using PerlHandler. Why is the code working inside a
PerlHandler
module and not in PerlAccessHandler?
PerlHandler's don't require a return value (although it's best to do so in
case you want to chain several of them together). PerlAccessHandler's must
return OK, FORBIDDEN or DECLINED.
Hope that helps,
Chris
Re: cookies cookies cookies
Greg Stark wrote:
How do I reliably remove a cookie from a browser's memory? I've only just
begun to experiment but it seems if I set the cookie to "" or undef
Apache::ASP doesn't send the right headers to remove the cookie. (Actually
undef seems to corrupt the cookie). I could just write a handler to set the
header appropriately but I'm not even sure what I should be putting in the
header.
What about setting the cookie with an expires date in the past?
$Response-{Cookies}{YourCookie} = {
Value = '',
Expires = -86400,
};
-- Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: cookies cookies cookies
At 01:47 PM 12/12/00, Joshua Chamas wrote:
Greg Stark wrote:
How do I reliably remove a cookie from a browser's memory?
Then Josh said:
What about setting the cookie with an expires date in the past?
$Response-{Cookies}{YourCookie} = {
Value = '',
Expires = -86400,
};
In most cases, this will only work for a cookie that is an _exact_
match with the one you wish to expire. This is really hard to do
if your code didn't write the cookie, since most browsers will use
the 'path' and 'domain' values to evaluate exactness, but do not
send those values to you in a request, obscuring them.
While writing a cookie handling library, I found it necessary to
trash my cookies file when things got weird, since writing code
to remove cookies that were the result of bad code seemed a waste
of time. Once it was stable it worked rather well, assuming that
calls to the library were consistent about 'path' and 'domain'.
Unless you're required to use 'path', I recommend that you explicitly
set 'path' to '/' on all set cookie operations, and similarly make
use of a canonical 'domain' value. Then it will be easy to construct
'kill cookies'. Otherwise, you'll have to construct logic to determine
the right 'path' and 'domain' for a particular cookie (yech).
-jh
Re: Cookies
Jeff Smelser wrote:
How do you set expires in ASP cookies?
I tried, and various other ways too. Even nodeworks.com wouldn't work for
me. Thanks.
$expires=HTTP::Date::time2str(time()+86400);
$Response-{Cookies}{'username','Expires', '$expires'} =
$Request-Form('username');
$Response-{Cookies}{'password'} = $Request-Form('password');
Try:
$Response-{Cookies}{username} = {
Expires = 86400,
Value = $Request-{Form}{username}
};
or
$Response-Cookies('username', 'Expires', 86400);
$Response-Cookies('username', 'Value', $Request-Form('username'));
See the $Response-Cookies collection in the OBJECTS section
of the README or the website http://www.apache-asp.org
-- Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: Cookies
On Tue, 23 May 2000, Jim Serio wrote:
Like I said, the cookie is being set, but I can't read the cookie.
Apache::Cookie-fetch('cookie_name'); doesn't work.
this is a fixup handler? you shouldn't be sending the complete http
header there. you should use $r-headers_out like you did in your
original example. and, use telnet to see what your module is actually
sending, or a log handler that dumps $r-as_string, or Apache::DumpHeaders
(on cpan).
This brings up a not-so-mod_perl question. Is there a way to telnet
to name-based virtual hosts? Can I spoof the GET request?
telnet address 80
GET / HTTP/1.1
Host: virtualhost
return
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: Cookies
"JS" == Jim Serio [EMAIL PROTECTED] writes: JS This brings up a not-so-mod_perl question. Is there a way to telnet JS to name-based virtual hosts? Can I spoof the GET request? No need to spoof anything, the protocol is entirely ASCII so you can just type the proper commands in your telnet window. Or do it the easy way and use the LWP modules for perl.
Re: Cookies (domains now working!)
--Geoff--
Also, as I mentioned earlier, I couldn't get "domain=...;" to work.
make sure that the domain has a dot in front of it and that it
matches the hostname of the box (RFC 2109):
$headers_out-add('Set-Cookie', "name=$val; domain=.foo.com;");
Ah-HA! I *don't* think I used a dotThat was it!
LATINmultas gratias tibi do!/LATIN
TRANSThanks, lots. =o) /TRANS
Paul
Printed across the top of Folger's Gourmet Coffee Singles packets:
"100% COFFEE WITH ADDED FLAVORS"
=
"Seize the wildness of the moment, Feel the movement of the moon -- Swans fly with
wings wide open to the sky." -- B-52's
-
Real friends are those whom, when you inconvenience them, it bothers you more than
them. -- me. =o)
-
"There are trivial truths and there are great Truths. The opposite of a trival truth
is obviously false. The opposite of a great Truth is also true." -- Neils Bohr
-
TEMPVS PECVDEM COLLARE EST - It's time to thin the herd.
-
[http://www.catfishforbreakfast.com/letgod.html]
-
__
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/
Re: Cookies
On Mon, 22 May 2000, Jim Serio wrote: I'm still having trouble writing cookies while using Apache::Sandwich (thanks Vivek for the explination). Searching through the list archives, I found an example from David Pisoni to add the cookie to an image using the PerlFixupHandler. It doesn't seem to be workign for me though.. I also tried using CGI (in the handler) to write out the cooke with the same results. Here's the snippet from httpd.conf: Location /images/header_top_left.gif PerlFixupHandler Cookieme /Location And here's teh entire Cookieme module: i dropped your code in mod_perl-1.xx/t/docs/startup.pl and config in t/conf/httpd.conf (in the /perl/perl-status Location), it works just fine. your cookie format looks wrong though, maybe netscape can't parse it? % telnet localhost 8529 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. GET /perl/perl-status http/1.0 HTTP/1.1 200 OK Date: Tue, 23 May 2000 18:07:06 GMT Server: Apache/1.3.13-dev (Unix) mod_perl/1.24_01-dev Perl/v5.6.0 Set-Cookie: cobrand=cobrand= ;domain=.hotwired.com;path=/ Connection: close Content-Type: text/html ...
Re: Cookies
Like I said, the cookie is being set, but I can't read the cookie.
Apache::Cookie-fetch('cookie_name'); doesn't work.
this is a fixup handler? you shouldn't be sending the complete http
header there. you should use $r-headers_out like you did in your
original example. and, use telnet to see what your module is actually
sending, or a log handler that dumps $r-as_string, or Apache::DumpHeaders
(on cpan).
This brings up a not-so-mod_perl question. Is there a way to telnet
to name-based virtual hosts? Can I spoof the GET request?
Jim
Re: Cookies
On Tue, 23 May 2000, Jim Serio wrote:
Like I said, the cookie is being set, but I can't read the cookie.
Apache::Cookie-fetch('cookie_name'); doesn't work.
this is a fixup handler? you shouldn't be sending the complete http
header there. you should use $r-headers_out like you did in your
original example. and, use telnet to see what your module is actually
sending, or a log handler that dumps $r-as_string, or Apache::DumpHeaders
(on cpan).
This brings up a not-so-mod_perl question. Is there a way to telnet
to name-based virtual hosts? Can I spoof the GET request?
telnet www.thesite.com 80
Trying xxx.xxx.xxx.xxx...
Connected to www.thesite.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.virtualhost.com
HTTP/1.1 200 OK
Server: blah blah blah blah
...
Cheers,
Jeffrey
Re: Cookies and redirection
On 09-May-2000 Perrin Harkins wrote: Bill Desjardins wrote: I checked the archives and the guide to no avail, so here goes. I am having trouble setting a cookie in the header and then doing a redirect. The cookies are working fine every where, but if I add a cookie to $r-headers_out-add(), set a location via $r-headers_out(Location = 'newrui') and return REDIRECT, I get no cookies being set. is this a bug, feature, or a feature of the wonderful world of incompatible browsers? This is a known problem with certain browsers. The cookie will get set, but will not get returned on this first redirect. You could try putting the cookie data in a query string and looking for it there when it isn't in the cookie. - Perrin Here's how I got it work to flawlessly (probably not the 'correct' way of doing it, though :) $r-send_cgi_header(EOF); Set-cookie: admin_id=0; path=/ Set-cookie: admin_key=0; path=/ Location: / EOF return DONE; Regards, Wim Kerkhoff, Software Engineer NetMaster Networking Solutions [EMAIL PROTECTED]
Re: Cookies and redirection
not completely sure about real mod_perl. However, the following works
great using Apache::Registry and CGI:
print $query-header(-cookie=[$id_cookie,$crypt_cookie],
-Location=$query-param("redirect").'?name='.@$ref[1].'last_login='.@$ref[3].'site_id='.$query-
param('site_id'));
I think Apache::Request will work just in same manner.
-amen
On Tue, 9 May 2000, Robin Berjon wrote:
At 00:13 09/05/2000 -0700, Perrin Harkins wrote:
Bill Desjardins wrote:
I checked the archives and the guide to no avail, so here goes. I am
having trouble setting a cookie in the header and then doing a
redirect. The cookies are working fine every where, but if I add a cookie
to $r-headers_out-add(), set a location via $r-headers_out(Location =
'newrui') and return REDIRECT, I get no cookies being set. is this a bug,
feature, or a feature of the wonderful world of incompatible browsers?
This is a known problem with certain browsers. The cookie will get set,
but will not get returned on this first redirect. You could try putting
the cookie data in a query string and looking for it there when it isn't
in the cookie.
Isn't there a work-around consisting of making 100% sure the cookie is sent
before the Location header ?
.Robin
All paid jobs absorb and degrade the mind. -- Aristotle
Re: Cookies and redirection
At 08:53 09/05/2000 -0700, Perrin Harkins wrote: On Tue, 9 May 2000, Robin Berjon wrote: Isn't there a work-around consisting of making 100% sure the cookie is sent before the Location header ? Not with MSIE. At least it didn't work for me. Works here for me with msie 4 and 5.1 on win98. .Robin Does the name Pavlov ring a bell?
Re: Cookies and redirection
On Tue, 9 May 2000, Alex Menendez wrote:
not completely sure about real mod_perl. However, the following works
great using Apache::Registry and CGI:
print $query-header(-cookie=[$id_cookie,$crypt_cookie],
-Location=$query-param("redirect").'?name='.@$ref[1].'last_login='.@$ref[3].'site_id='.$query-
param('site_id'));
I think Apache::Request will work just in same manner.
First, why the @$ref[1]? YOu're doing a slice when you really want
$ref-[1]. Anway, Apache::Request does not have any output methods like
CGI so this won't work.
Try checking out Apache::Cookie for the cookie part. For the redirect you
can do:
$r-header_out( Location = $location );
and then make sure that you send a REDIRECT status to the browser. (Return
REDIRECT from your module).
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Cookies and redirection
On Tue, 2 May 2000, Bill Desjardins wrote: Hi all, I checked the archives and the guide to no avail, so here goes. I am having trouble setting a cookie in the header and then doing a redirect. The cookies are working fine every where, but if I add a cookie to $r-headers_out-add(), set a location via $r-headers_out(Location = 'newrui') and return REDIRECT, I get no cookies being set. is this a bug, feature, or a feature of the wonderful world of incompatible browsers? try $r-err_headers_out-add instead.
Re: Cookies
Hi,
I had the same problem the server not sending any cookies.
I don't think it has got to do with the 403 STATUS code:
My Code contains:
# add cookie file to HTTP header
$r-err_headers_out-add('Set-Cookie' = $cookie);
$r-no_cache(1);
# trigger 403 ErrorDocument redirect
return
FORBIDDEN;
My problem was that I tested my handler with the following URL in the
browser:
http://hostname/...
omitting the Domain that I previously set in the cookie.
Altering the URL to
http://hostname.domain/...
does the trick for me.
Ciao
Axel
