|
Re: Cookie Hell
by DamnDirtyApe (Curate) on Jul 07, 2002 at 00:49 UTC
|
Have you consulted the HTTP Cookies section of he CGI docs? If not, go have a read. If you have, could you perhaps post the section of the code where you are attempting unsuccessfully to set the cookie? It would be most helpful.
Update:
What? You're not using CGI?
DamnDirtyApe gives TexasTess the obligatory disapproving look. ;-)
Anyway, I Googled the specs from netscape.com on HTTP Cookies. Maybe there's something there for you.
_______________
D
a
m
n
D
i
r
t
y
A
p
e
Home Node
|
Email
| [reply] |
|
|
Thanks for the Google...I'd already Googled the master of CGI Cookie hell googles but it looks like you've turned up a few new pages that I can investigate tomorrow.
I am working with SO many restrictions...no classes allowed...only java script...no modules save CGI.pm and we only got that a little more than a week ago. No windows interfaces..and netscape is the sole browser...
Thanks again!
TexasTess
| [reply] |
Re: Cookie Hell
by TexasTess (Beadle) on Jul 07, 2002 at 01:02 UTC
|
Can't post the code...it's at work...can't post to the net from work...can't bring my work home. I'm not using CGI.pm so I am using the set-Cookie:foo=blah;expires=blah method.
Since I posted I have thought of a couple syntax errors that could be the latest culprit...but what I usually end up with is the cookie line printing literally in the produced webpage (I am using pure CGI to generate all my HTML dynamically) OR the headers line prints to the page literally.
I've found that you can't interchange the CGI.pm and raw form code ....once you use a $foo = new CGI all form data that is parsed ends up in the $foo->param variable ...
So ..no thoughts about being able to "unset" headers once their set?
TexasTess
Great Spirits often encounter violent opposition from mediocre minds" --Einstein | [reply] |
|
|
I've found that you can't interchange the CGI.pm and raw form code
Why would you want to? It's much safer to let CGI.pm take care of it for you.
I think that you could solve your problems by upgrading your code to use CGI.pm.
My thoughts are mine and mine alone. They did not originate with the voices in my head. Do not listen to what they say, it's all lies.
| [reply] |
|
|
The meat of the program is working like a charm and does not use CGI.pm. To convert it would mean days and days of work that I don't have time for...I agree that CGI.pm is very cool, but we didn't get it approved for installation until I'd gotten most of the project working.
I hate to think that I can get a database flatfile script to work....XORing passwords and validating entries without CGI.pm but can't get a simple cookie to set ?
TexasTess
| [reply] |
|
|
|
|
|
|
|
|
|
|
Re: Cookie Hell
by hacker (Priest) on Jul 07, 2002 at 21:10 UTC
|
You noted that you're not using CGI, but does that mean you can't use CGI and friends? Or you just aren't, for the current code? I've used CGI::Cookie successfully for quite some time, and it works well. Obviously for your design, you'll need to encode the password to obfuscate it, if you're passing that back as a token to the server; Digest::MD5 will help there, or one of the other more secure methods.
if ($ENV{'HTTP_COOKIE'} && $ENV{'HTTP_COOKIE'} =~ /vote/) {
$cookie_state = 1;
my (@rawCookies) = split (/; /,$ENV{'HTTP_COOKIE'});
my (%cookies);
foreach(@rawCookies){
($key, $val) = split (/=/,$_);
$cookies{$key} = $val;
}
foreach $name (keys %cookies) {
$cookie_value = $cookies{$name};
}
} else {
if ($action =~ /results/ && $poll) {
$c1 = new CGI::Cookie(-name => 'vote',
-value => [$poll],
-expires => '+1M'
);
print "Set-Cookie:", $c1, "\n";
}
}
$c2 = new CGI::Cookie(-name => 'plucker',
-value => 'true',
-expires => '+1h',
-path => '/',
-secure => '0',
);
$plucker = cookie('plucker');
if (!$plucker) {
print header(-cookie=>[$c2]);
} else {
print header() if ($type ne "Plucker");
}
Also, noticed you mention that you can't 'unset' headers. You certainly can, if you put those headers in a scalar, and undef() them later on, as required. Without code and not knowing your design, I can't say whether this is the right longer-term approach, but it will allow you to 'unset' them at will. | [reply]
[d/l] |
|
|
#1 Thanks for the great example and indepth reply...I'll find it very useful for completing my project!
#2. I didn't say I "couldn't" use CGI.pm, I said that by the time the admin folks got it functional...I'd already completed an enormous amount of code and I "can't" sometimes use it and sometimes not use it because the form data defaults to $foo->param and is as a result unavailable to the existing 3k lines of code already developed.
#3. I didn't say I "Couldn't" unset headers..I was asking if there was a way to unset them...that is really the gist of the original post. You've answered that question with the undef() idea and you've also given me another option using the CGI::Cookie module that will not interfere with my form processing and for that I am Greatful beyond words!
I've solved my issue today while at work, there were a couple of syntax errors along with a need to change my method for writing the headers...and VIOLA, I am a cookie connoisseur!
I seriously cannot believe how difficult it is to find a good reference book for programming in CGI/PERL/CGI.pm. I've purchased 6 books since starting this project and find myself constantly frustrated at how scattered they are! They either expect you to follow their strict programming styles totally or you can't use their examples, or they skip and jump around..never really DEFINING and ILLUSTRATING any one issue in any depth! THANK GOD (OR IS IT MONKS!?!) for this site!!
TexasTess
"Great Spirits Often Encounter Violent Opposition From Mediocre Minds" --Einstein
| [reply] |
Re: Cookie Hell
by Mr. Muskrat (Canon) on Jul 07, 2002 at 00:53 UTC
|
Post your code so we can see where it's going wrong.
| [reply] |
