cookies

[aman cgiperl]

Hi all
I need to set a cookie which expires when the browser is closed.
I am not using CGI.pm
My earlier query for the same for responded by telling that if I am using
CGI.pm, I can do so by omitting the expiry date, but if I do so, when I do

print "Set-Cookie: cart=$cart domain=.domain.com\n";

the cookie does not get set at all.

Thanks for suggestions in advance.
Aman

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cookies

[Stephen Spalding]

Hello all,

Can anyone point me to some good doc on how to
create/read/delete cookies?

Thanks!

-Stephen Spalding

__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookies

[Alejandro Chavarria - CyPage]

Hey,

I have a script and I want to allow an administrator log on to it.  Once
logged in they can change things... etc.  Basically stuff I don't want other
people to be able to do.  I have decided that cookies is the best way to go.
I've been looking and looking on the internet for a way to add a "logout"
button in the script that will delete the cookie that has the username and
password so they are essentially logged out.  I have read that you can fill
in the "expires" field in with 1. a date in the past (ie. -1d) or 2. the
word "now".  I have heard about problems with both these methods.

What do you suggest?

Alex


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cookies

[Jerry Preston]

Hi!

I guess I am missing the boat.  I have read CGI::Cookie and played with the code, but 
I would think that I should be able to read the netscape cookies
file in by NT system.  My script is running on a unix server.  Is this possible.  I 
have tried to set a cookie and the read it,  no luck.  

print "env $ENV{'HTTP_COOKIE'} ";


 $c = new CGI::Cookie( -name=>  'Testing',
   -value   =>  [ "jwp", '[EMAIL PROTECTED]' ],
   -expires =>  '+3M',
   -domain  =>  '.xxx',
   -path=>  '/'
   -secure  =>  0
  );

  print "Set-Cookie: $c\n";
  print $query->header(-cookie=>$c);
  print "Set-Cookie: ",$c->as_string,"\n";

#Recovering Previous Cookies

 @defaults=$query->cookie('dm5apps.de.sc.ti.com');#'www.kitchenetc.com');

print "defaults *@defaults*";

 %cookies = fetch CGI::Cookie;
 foreach (keys %cookies) {
   print "$_ - ($cookies{$_})";
 }

Thanks for YOUR help,

Jerry

Cookies

[jason]

Need some help.  I am looking at using cookies.

For some of the things that I need to do I think that it will make my life 
easier.

I also HAVE to use CGI qw(:cgi-lib)

I am running Perl 5.6 and do not use the object oriented html function. I just 
want to use. 

print 'html';  etc..

Now to the point. How do I use cookies. 

Set
Get
Remove

I have examples for just CGI with object oriented html.


I have examples for just require cookie.pl;  

But I cannot seem to but it together.  I would really appriciate any help.

Thanks,
Jason

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookies ...

[Polikarpov Cyrill]

Hi everybody!

I'm working whith perl but I don't know how to work whith cookies. Give me please some 
tips for this one ...

Thanks :)

--
WBR,
Cyrill S. Polikarpov
[EMAIL PROTECTED]

cookies

[Matthew Harrison]

can someone show me an example of setting and retrieving a cookie using 
CGI.pm. I have tried the following but it won't set a cookie. I have my 
browser set to ask me whether i want to allow the cookies, and the script 
doesn't ask me:

#!/usr/bin/perl

use CGI qw/:standard/;
$q = new CGI;
print header();

$cookie = $q->cookie(-name=>'fontsize',
      -value=>'12',
      -expires=>'20s',
      -domain=>'http://www.peanutbuttercheesecake.co.uk');

is there something else I have to put to actually set the cookie instead of 
just defining it?

-- 
Matthew Harrison
Internet/Network Services Administrator
Peanut-Butter Cheesecake Hosting Services
Genstate
www.peanutbuttercheesecake.co.uk


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cookies

[mark]

Hi Everybody,

I've been moitoring the list for a little while and trying to learn a little something 
about Perl.  I finally got my site to spit out a cookie using some example code I got 
out of a book that I altered (my own code bombed)

What I find curious is a series of 4 numbers appended to the end of the information 
that I expected.

Here's the content of the cookie:

idksample
other&Other&login&djackson%40bellsouth.net
kleo.net/
0
3010804096
29561699
3411852896
29488274
*


I didn't see anything in the code that would have led me to expect anything after the 
kleo.net/

Why is that?

Thanks,
Mark

Re: cookies

[Trevor Wilkes]

I find wih IE alot of the times when you specify a domain it can be very
glitchy...

Trevor Wilkes
- Original Message -
From: "Robin Cragg" <[EMAIL PROTECTED]>
To: "'aman cgiperl'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 02, 2002 11:04 AM
Subject: RE: cookies


> Hi Aman,
>
> I've had exactly the same problem.  I strongly suspect it's an IE thing.
> I've not found a way round it other than looking at the HTTP_REFERER and
> removing cookies from pages that had not come from my site.
>
>
> R
>
>
>
> -Original Message-
> From: aman cgiperl [mailto:[EMAIL PROTECTED]]
> Sent: 02 October 2002 14:27
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: cookies
>
>
> Hi all
> I need to set a cookie which expires when the browser is closed. I am
> not using CGI.pm My earlier query for the same for responded by telling
> that if I am using CGI.pm, I can do so by omitting the expiry date, but
> if I do so, when I do
>
> print "Set-Cookie: cart=$cart domain=.domain.com\n";
>
> the cookie does not get set at all.
>
> Thanks for suggestions in advance.
> Aman
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies

[James Edward Gray II]

On Wednesday, October 2, 2002, at 08:26  AM, aman cgiperl wrote:

> I am not using CGI.pm

I don't mean to be offensive here, but why would you not use a standard 
Perl module that's only purpose is to make coding CGI easier?!

James


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: cookies

[Robin Cragg]

Hi Aman,

I've had exactly the same problem.  I strongly suspect it's an IE thing.
I've not found a way round it other than looking at the HTTP_REFERER and
removing cookies from pages that had not come from my site.


R



-Original Message-
From: aman cgiperl [mailto:[EMAIL PROTECTED]] 
Sent: 02 October 2002 14:27
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: cookies


Hi all
I need to set a cookie which expires when the browser is closed. I am
not using CGI.pm My earlier query for the same for responded by telling
that if I am using CGI.pm, I can do so by omitting the expiry date, but
if I do so, when I do

print "Set-Cookie: cart=$cart domain=.domain.com\n";

the cookie does not get set at all.

Thanks for suggestions in advance.
Aman

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RES: cookies

[Ricardo Luiz Chamberline Maturana]

I use the line:

print "Content-type: text/html\\nSet-Cookie: PS=$PS;\\n\\n";

and it works well.

[]´s
Ricardo 

RE: cookies

[Kipp, James]

> Hello all,
> 
> Can anyone point me to some good doc on how to
> create/read/delete cookies?
> 
> Thanks!
> 

Hi Stephen
I am new to cookies as well and recently posted a question like this. Here
is what I found helpful:
Here's a good overview:
http://wp.netscape.com/newsref/std/cookie_spec.html
Read the CGI.pm docs, there is a section on cookies
http://stein.cshl.org/WWW/CGI/#cookies
also take a look at CGI::Cookie -
http://www.perldoc.com/perl5.6/lib/CGI/Cookie.html
HTTP::Cookies: - http://www.perldoc.com/perl5.6/lib/HTTP/Cookies.html

If you rather not use these modules and create and read cookies by hand,
just do a google search and you will find plenty


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

shared cookies

[Hytham Shehab]

hi guys,
i have multiple domain names - etc multiple sites - that i would like to
share cookies inbetween, how can i - literally - do that, and is it enough
to use HTTP::Cookies !?

thx 4 help

--
Hytham Shehab



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cookies

[Wiggins d'Anconia]

On Wed, 17 Sep 2003 20:33:00 -0800, "Alejandro Chavarria - CyPage" <[EMAIL PROTECTED]> 
wrote:

> Hey,
> 
> I have a script and I want to allow an administrator log on to it.  Once
> logged in they can change things... etc.  Basically stuff I don't want other
> people to be able to do.  I have decided that cookies is the best way to go.
> I've been looking and looking on the internet for a way to add a "logout"
> button in the script that will delete the cookie that has the username and
> password so they are essentially logged out.  I have read that you can fill
> in the "expires" field in with 1. a date in the past (ie. -1d) or 2. the
> word "now".  I have heard about problems with both these methods.
> 
> What do you suggest?
> 

In general I would reset the cookie to the empty string with no expiration date, and 
then on the other end your check should be that the cookie exists *and* has a correct 
value.  Then make the "correct" value very hard (because nothing is 100% secure) to 
figure out how to generate. In other words hash it with a secret key or some such that 
only the server has.  So the cookie exists but the check fails, and as soon as the 
session ends the cookie is no longer stored.

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies

[Wiggins d'Anconia]

Alejandro Chavarria - CyPage wrote:
Thanks for your reply Wiggins d'Anconia.  I understand the part about just
setting the cookie to an empty value, but I don't understand the part about
the secret key and a check failing.  Could you explain further?  When would
this happen: initially setting the cookie's value, or everytime you check
the cookie to see if the username and password are correct?
Remember to group reply so everyone can help and be helped.  Essentially 
you would take the username and password once, at that time you create a 
hashed value of some user information such as an id # or the username if 
you want, etc. and any other information you want, IP and expiration 
time, plus a "secret" key, basically any phrase that your site knows 
that no one else does. (insert rant about how that is not secure because 
anyone with access to the code can see it, blah blah blah...) and you 
hash the values together (check out Digest::MD5 or Digest:SHA1 for two 
good hashing modules, I prefer the second for other reasons). Then each 
time you want to verify the user is who they say they are you take the 
information they provide (aka their username or id as mentioned above) 
and the hash you generated above which can be stored in teh same cookie 
and then you create the hash in the same manner as before and check to 
see that the hashes match.  (There is a much better explanation on this 
with code samples in the O'Reilly Apache Modules with Perl and C book.)

It is *very difficult* (nothing is completely secure) for the user to 
create a hash that will be authentic based only on the knowledge they 
have, aka what the cookie looks like and what their user id is. They 
could guess that you are using a hash of something fairly easily, and 
that if their user id is 245 that there is probably user ids 1-244 but 
they can't guess your secret passphrase so to recreate a hash is nearly 
impossible.

This also prevents the need to be passing the username/password around 
other than on initial login, and is much better than simply setting a 
single cookie and checking for its existence for obvious reasons.

Examples:

#
#  Method to generate authentication cookie
#
use Digest::SHA1;
sub authentication_string {
my $self = shift;
my $uid = $self->id;
my $time = time;
my $expires = 2592000;
my $data = join(':', CONFIG_AUTH_KEY, $time, $expires, $uid);
my $hash = Digest::SHA1::sha1_hex($data);
return "uid=$uid time=$time expires=$expires hash=$hash";
}
The above code assumes a 'User' object with an instance method of 'id' 
that returns the user's id, and a constant CONFIG_AUTH_KEY that contains 
the site's "secret" key.

I leave the method for validating the authentication to the reader 
(mostly because mine has lots of non-standard error checking in it).

Thoughts/comments from any of the gurus?

http://danconia.org


-Original Message-
From: Wiggins d'Anconia [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 6:17 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Cookies



On Wed, 17 Sep 2003 20:33:00 -0800, "Alejandro Chavarria - CyPage"
<[EMAIL PROTECTED]> wrote:

Hey,

I have a script and I want to allow an administrator log on to it.  Once
logged in they can change things... etc.  Basically stuff I don't want
other

people to be able to do.  I have decided that cookies is the best way to
go.

I've been looking and looking on the internet for a way to add a "logout"
button in the script that will delete the cookie that has the username and
password so they are essentially logged out.  I have read that you can
fill

in the "expires" field in with 1. a date in the past (ie. -1d) or 2. the
word "now".  I have heard about problems with both these methods.
What do you suggest?



In general I would reset the cookie to the empty string with no expiration
date, and then on the other end your check should be that the cookie exists
*and* has a correct value.  Then make the "correct" value very hard (because
nothing is 100% secure) to figure out how to generate. In other words hash
it with a secret key or some such that only the server has.  So the cookie
exists but the check fails, and as soon as the session ends the cookie is no
longer stored.
http://danconia.org




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cookies

[Alejandro Chavarria - CyPage]

Thanks.  I will try that.

Alex

-Original Message-
From: Wiggins d'Anconia [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 20, 2003 7:24 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Cookies


Alejandro Chavarria - CyPage wrote:
> Thanks for your reply Wiggins d'Anconia.  I understand the part about just
> setting the cookie to an empty value, but I don't understand the part
about
> the secret key and a check failing.  Could you explain further?  When
would
> this happen: initially setting the cookie's value, or everytime you check
> the cookie to see if the username and password are correct?
>

Remember to group reply so everyone can help and be helped.  Essentially
you would take the username and password once, at that time you create a
hashed value of some user information such as an id # or the username if
you want, etc. and any other information you want, IP and expiration
time, plus a "secret" key, basically any phrase that your site knows
that no one else does. (insert rant about how that is not secure because
anyone with access to the code can see it, blah blah blah...) and you
hash the values together (check out Digest::MD5 or Digest:SHA1 for two
good hashing modules, I prefer the second for other reasons). Then each
time you want to verify the user is who they say they are you take the
information they provide (aka their username or id as mentioned above)
and the hash you generated above which can be stored in teh same cookie
and then you create the hash in the same manner as before and check to
see that the hashes match.  (There is a much better explanation on this
with code samples in the O'Reilly Apache Modules with Perl and C book.)

It is *very difficult* (nothing is completely secure) for the user to
create a hash that will be authentic based only on the knowledge they
have, aka what the cookie looks like and what their user id is. They
could guess that you are using a hash of something fairly easily, and
that if their user id is 245 that there is probably user ids 1-244 but
they can't guess your secret passphrase so to recreate a hash is nearly
impossible.

This also prevents the need to be passing the username/password around
other than on initial login, and is much better than simply setting a
single cookie and checking for its existence for obvious reasons.

Examples:

#
#  Method to generate authentication cookie
#
use Digest::SHA1;
sub authentication_string {
 my $self = shift;


 my $uid = $self->id;
 my $time = time;
 my $expires = 2592000;


 my $data = join(':', CONFIG_AUTH_KEY, $time, $expires, $uid);
 my $hash = Digest::SHA1::sha1_hex($data);


 return "uid=$uid time=$time expires=$expires hash=$hash";
}


The above code assumes a 'User' object with an instance method of 'id'
that returns the user's id, and a constant CONFIG_AUTH_KEY that contains
the site's "secret" key.

I leave the method for validating the authentication to the reader
(mostly because mine has lots of non-standard error checking in it).

Thoughts/comments from any of the gurus?

http://danconia.org


>
> -Original Message-
> From: Wiggins d'Anconia [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2003 6:17 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Cookies
>
>
>
> 
> On Wed, 17 Sep 2003 20:33:00 -0800, "Alejandro Chavarria - CyPage"
> <[EMAIL PROTECTED]> wrote:
>
>
>>Hey,
>>
>>I have a script and I want to allow an administrator log on to it.  Once
>>logged in they can change things... etc.  Basically stuff I don't want
>
> other
>
>>people to be able to do.  I have decided that cookies is the best way to
>
> go.
>
>>I've been looking and looking on the internet for a way to add a "logout"
>>button in the script that will delete the cookie that has the username and
>>password so they are essentially logged out.  I have read that you can
>
> fill
>
>>in the "expires" field in with 1. a date in the past (ie. -1d) or 2. the
>>word "now".  I have heard about problems with both these methods.
>>
>>What do you suggest?
>>
>
>
> In general I would reset the cookie to the empty string with no expiration
> date, and then on the other end your check should be that the cookie
exists
> *and* has a correct value.  Then make the "correct" value very hard
(because
> nothing is 100% secure) to figure out how to generate. In other words hash
> it with a secret key or some such that only the server has.  So the cookie
> exists but the check fails, and as soon as the session ends the cookie is
no
> longer stored.
>
> http://danconia.org
>
>



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies

[Ramon Chavez]

I'm not a guru... ;-P
But I was in a similar situation some months ago.

First of all I would tell Alejandro not to send Username-Password with the
cookie, but a Session ID, but I arrived late.

There are two modules (at least I only know them) to handle "sessions" with
cookies. Apache::Session and CGI::Session
Even been them complete solutions (I think so, I haven't really used them),
not all systems support them, that's my case, my web host doesn't has any of
them installed (That's because I haven't used them).

My suggestion is to create sessions, using cookies and generating the ID as
described in the previous message (not mine). But in Alex situation he might
want to give access only to the Administrator, wich makes things easier.

I am not sure right now, but I believe that I found useful hints in an
online course, from Ovid

Check this link
http://users.easystreet.com/ovid/cgi_course/

-rm-
- Original Message -
From: "Wiggins d'Anconia" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, September 20, 2003 10:24 AM
Subject: Re: Cookies


> Alejandro Chavarria - CyPage wrote:
> > Thanks for your reply Wiggins d'Anconia.  I understand the part about
just
> > setting the cookie to an empty value, but I don't understand the part
about
> > the secret key and a check failing.  Could you explain further?  When
would
> > this happen: initially setting the cookie's value, or everytime you
check
> > the cookie to see if the username and password are correct?
> >
>
> Remember to group reply so everyone can help and be helped.  Essentially
> you would take the username and password once, at that time you create a
> hashed value of some user information such as an id # or the username if
> you want, etc. and any other information you want, IP and expiration
> time, plus a "secret" key, basically any phrase that your site knows
> that no one else does. (insert rant about how that is not secure because
> anyone with access to the code can see it, blah blah blah...) and you
> hash the values together (check out Digest::MD5 or Digest:SHA1 for two
> good hashing modules, I prefer the second for other reasons). Then each
> time you want to verify the user is who they say they are you take the
> information they provide (aka their username or id as mentioned above)
> and the hash you generated above which can be stored in teh same cookie
> and then you create the hash in the same manner as before and check to
> see that the hashes match.  (There is a much better explanation on this
> with code samples in the O'Reilly Apache Modules with Perl and C book.)
>
> It is *very difficult* (nothing is completely secure) for the user to
> create a hash that will be authentic based only on the knowledge they
> have, aka what the cookie looks like and what their user id is. They
> could guess that you are using a hash of something fairly easily, and
> that if their user id is 245 that there is probably user ids 1-244 but
> they can't guess your secret passphrase so to recreate a hash is nearly
> impossible.
>
> This also prevents the need to be passing the username/password around
> other than on initial login, and is much better than simply setting a
> single cookie and checking for its existence for obvious reasons.
>
> Examples:
>
> #
> #  Method to generate authentication cookie
> #
> use Digest::SHA1;
> sub authentication_string {
>  my $self = shift;
>
>
>  my $uid = $self->id;
>  my $time = time;
>  my $expires = 2592000;
>
>
>  my $data = join(':', CONFIG_AUTH_KEY, $time, $expires, $uid);
>  my $hash = Digest::SHA1::sha1_hex($data);
>
>
>  return "uid=$uid time=$time expires=$expires hash=$hash";
> }
>
>
> The above code assumes a 'User' object with an instance method of 'id'
> that returns the user's id, and a constant CONFIG_AUTH_KEY that contains
> the site's "secret" key.
>
> I leave the method for validating the authentication to the reader
> (mostly because mine has lots of non-standard error checking in it).
>
> Thoughts/comments from any of the gurus?
>
> http://danconia.org
>
>
> >
> > -Original Message-
> > From: Wiggins d'Anconia [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, September 18, 2003 6:17 AM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: RE: Cookies
> >
> >
> >
> > 
> > On Wed, 17 Sep 2003 20:33:00 -0800, "Alejandro Chavarria - CyPage"
> > <[EMAIL PROTECTED]> wrote:
> >
> &g

Clearing cookies

[Denzil Kruse]

Hi all,

I'm trying to clear a cookie using CGI::Cookies, and
can't seem to do it :(

if ($clear_cookie eq 'yes') {

 my %cookies = fetch CGI::Cookie;

 print "getting cookie";

 if ($cookies{'id'}) {

  print "clearing cookie";
  $cookies{'id'}->expires('-1s');
  print "cleared cookie";
 }
}

I'm getting the "cleard cookie" message, but it is
still there.

Denzil




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Retrieving cookies

[Stokes, John]

I've figured out how to set a cookie, and I think I've retrieved it
successfully (no errors, at least), but now how do I manipulate it? I can't
figure out how to reference the cookie data.

Here's an example of my code:

use CGI;
$q = new CGI();
$myCookie = $q->cookie(-name=>'Fyre',
   
-value=>test,
   -expires=>'+3M',
   
-domain=>'.biola.edu');
print $q->header(-cookie=>$myCookie);

%cook = 
$q->cookie(-name=>'Fyre'); 


Now what?

-John Stokes

RE: cookies

[Bradley M. Handy]

> -Original Message-
> From: Jerry Preston [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 11, 2001 7:29 AM
> To: cgi
> Subject: cookies
>
>
> Hi!
>
> I guess I am missing the boat.  I have read CGI::Cookie and
> played with the code, but I would think that I should be able to
> read the netscape cookies
> file in by NT system.  My script is running on a unix server.  Is
> this possible.  I have tried to set a cookie and the read it,  no luck.
>
> print "env $ENV{'HTTP_COOKIE'} ";
>
>
>  $c = new CGI::Cookie( -name=>  'Testing',
>-value   =>  [ "jwp", '[EMAIL PROTECTED]' ],
>-expires =>  '+3M',
>-domain  =>  '.xxx',
>-path=>  '/'
>-secure  =>  0
>   );
>
>   print "Set-Cookie: $c\n";
>   print $query->header(-cookie=>$c);
>   print "Set-Cookie: ",$c->as_string,"\n";
>
> #Recovering Previous Cookies
>
>  @defaults=$query->cookie('dm5apps.de.sc.ti.com');#'www.kitchenetc.com');

The above line should be:
@defaults = $query->cookie('Testing');  # always fetch a cookie with the
name you gave it.

>
> print "defaults *@defaults*";
>
>  %cookies = fetch CGI::Cookie;
>  foreach (keys %cookies) {
>print "$_ - ($cookies{$_})";


The above line should be:
print "$_ - " . $cookie{$_}->value . "";

fetch CGI::Cookie returns a hash of CGI::Cookie objects with the key as the
name of the cookie.

>  }
>
> Thanks for YOUR help,
>
> Jerry
>

Re: cookies

[Jerry Preston]

Bradley,

When I use:

 print "$_ - " . $cookie{$_}->value . "";

I get "Can't call method "value" on an undefined value"!

Any ideas?

Thanks,

Jerry

"Bradley M. Handy" wrote:
> 
> > -Original Message-
> > From: Jerry Preston [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, July 11, 2001 7:29 AM
> > To: cgi
> > Subject: cookies
> >
> >
> > Hi!
> >
> > I guess I am missing the boat.  I have read CGI::Cookie and
> > played with the code, but I would think that I should be able to
> > read the netscape cookies
> > file in by NT system.  My script is running on a unix server.  Is
> > this possible.  I have tried to set a cookie and the read it,  no luck.
> >
> > print "env $ENV{'HTTP_COOKIE'} ";
> >
> >
> >  $c = new CGI::Cookie( -name=>  'Testing',
> >-value   =>  [ "jwp", '[EMAIL PROTECTED]' ],
> >-expires =>  '+3M',
> >-domain  =>  '.xxx',
> >-path=>  '/'
> >-secure  =>  0
> >   );
> >
> >   print "Set-Cookie: $c\n";
> >   print $query->header(-cookie=>$c);
> >   print "Set-Cookie: ",$c->as_string,"\n";
> >
> > #Recovering Previous Cookies
> >
> >  @defaults=$query->cookie('dm5apps.de.sc.ti.com');#'www.kitchenetc.com');
> 
> The above line should be:
> @defaults = $query->cookie('Testing');  # always fetch a cookie with the
> name you gave it.
> 
> >
> > print "defaults *@defaults*";
> >
> >  %cookies = fetch CGI::Cookie;
> >  foreach (keys %cookies) {
> >print "$_ - ($cookies{$_})";
> 
> The above line should be:
> print "$_ - " . $cookie{$_}->value . "";
> 
> fetch CGI::Cookie returns a hash of CGI::Cookie objects with the key as the
> name of the cookie.
> 
> >  }
> >
> > Thanks for YOUR help,
> >
> > Jerry
> >

Info Cookies

[alex.tesi]

Hi
i'd like to make a cookies and read that cookies from al page of my site.
Any of you can help me?

Thankyou by AlexTesi

Re: Cookies ...

[Briac Pilpré]

Polikarpov Cyrill wrote:
> I'm working whith perl but I don't know how to work whith cookies. Give 
> me please some tips for this one ...

 A good start would probably be to read the documentation of
 HTTP::Cookies
 perldoc HTTP::Cookies
 or
 http://search.cpan.org/doc/GAAS/libwww-perl-5.63/lib/HTTP/Cookies.pm

 The CGI modules also offers support of cookies and have good examples
 on how to use them in it documentation:
 perldoc CGI
 or
 http://search.cpan.org/doc/LDS/CGI.pm-2.79/CGI.pm
 (search for the section called HTTP Cookies)

 A good read is merlyn's Web Techniques, at least two of them deals
 directly with cookies:
 http://www.stonehenge.com/merlyn/WebTechniques/col61.html
 http://www.stonehenge.com/merlyn/WebTechniques/col32.html
 
 A lot of other articles are using Cookies too, and they're probably
 the best commented examples you could find.

 Hope this helps,
 Briac

-- 
briac
Two kingfishers flying 
towards the west. Master Po 
near the market-place.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Setting cookies

[Octavian Rasnita]

Hi all,

I just made a script which set cookies, and it works fine.
But I tried to disable the cookies from my machine and if I open that page
which set cookies, they are still set and read, even they are disabled.

Do you have any idea why?
Can't I disable the cookie  for a local HTML document?
Or, is the Perl script I did so powerfull that it doesn't care about my
settings?

Thank you for some light.

Teddy,
My dear email address is [EMAIL PROTECTED]



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Session cookies

[Octavian Rasnita]

Hi all,

I want to set a cookie in a Perl script only for the current session, and I
don't need that cookie after the visitor closes the browser.

Can I use this kind of cookie if the user has deactivated cookies in her
browser?

I can't test this on my localhost, because even if I disable the cookies,
they are set with no problem.

Thank you.
Teddy,
My dear email address is [EMAIL PROTECTED]



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies

[eric-perl]

On Tue, 12 Mar 2002, Matthew Harrison wrote:
> #!/usr/bin/perl
> 
> use CGI qw/:standard/;
> $q = new CGI;
> print header();
> 
> $cookie = $q->cookie(-name=>'fontsize',
>       -value=>'12',
>       -expires=>'20s',

Matt:

You must print the output of CGI.pm to STDOUT. e.g., 

my $cookie = cookie(name => 'value');
print header($cookie),
start_html(),
h1('The Devil is in the details'), 
end_html();

I suggest that you read ALL of the example code.

-- 
Eric P.
Los Gatos, CA


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies

[Randal L. Schwartz]

>>>>> "Matthew" == Matthew Harrison <[EMAIL PROTECTED]> writes:

Matthew> can someone show me an example of setting and retrieving a cookie using 
Matthew> CGI.pm. I have tried the following but it won't set a cookie. I have my 
Matthew> browser set to ask me whether i want to allow the cookies, and the script 
Matthew> doesn't ask me:

Please read 

http://www.stonehenge.com/merlyn/WebTechniques/col61.html

before proceeding.  It may be all you need to know. :)


-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies

[mark]

The URL to the code:

http://kleo.net/cookie2.txt

Redirect and cookies

[Alex Agerholm]

Hi all,

I have a problem with redirect.
I have made a login system and when the user has logged in correctly I set a
cookie and redirects the user to the first page.
But on all pages (including the first one) I make a check to see if the user
is logged in based on the cookie.

When I redirect from the login page to the first page I therefore need to
give the cookie along like:  redirect( -uri=>xxx.cgi, -cookie=>$cookie);
BUT IT DOES NOT WORK - my xxx.cgi script does not get the cookie.
What can I do to fix this ?

Regards
Alex



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RES: cookies (FIX)

[Ricardo Luiz Chamberline Maturana]

The correct line does not have "double back slash".

I use the line as the first line of my CGI script:

print "Content-type: text/html\nSet-Cookie: PS=$PS;\n\n";

and it works fine.

[]´s
Ricardo 

> - Mensagem original -
> De:   Ricardo Luiz Chamberline Maturana 
> Enviada em:   quarta-feira, 2 de outubro de 2002 12:38
> Para: 'Robin Cragg'; 'aman cgiperl'; [EMAIL PROTECTED]
> Cc:       [EMAIL PROTECTED]
> Assunto:  RES: cookies
> 
> I use the line:
> 
>   print "Content-type: text/html\\nSet-Cookie: PS=$PS;\\n\\n";
> 
> and it works well.
> 
> []´s
> Ricardo 

Help with Cookies

[Kipp, James]

> All am I am trying to do now is have a user enter his/her 
> name in a form and have that saved to a cookie, so when they 
> return, they will get something like " Your juser, please 
> proceed" . I took the example here: 
> http://stein.cshl.org/WWW/CGI/examples/cookie.cgi
> 
> Below is the code I am working with.  But when I return to 
> the page I just get the form again. What am i missing. Sorry 
> if this is obvious, but i am not getting it and I have read 
> the tutorial and the RFC on http state (thanks John ).

I revised the code to get rid of the obvious mistakes. I can see that the
cookie is made, but how can get it to print the user after it reads that
there is indeed a a cookie. 
here is what i have now:
---
use CGI qw(:standard);
# get cookie if it is there
%all = cookie('user');
# Recover the new users from the form parameter 'new_user'
$new = param('new_user'); 

# Add  the user submitted in the form as the new cookie
$cookie = cookie(-name=>'user',
 -value=>$new,
 -expires=>'+1h');

# Print the header, incorporating the cookie and the expiration date...
print header(-cookie=>$cookie);
# Now we're ready to create our HTML page.
print start_html('Test cookie');

if (%all) { # shouldn't it print if there is a cookie
found??
foreach $key ( keys %all) {
print "$all{$key}";
}
}
else { print " NO USERS SAVED " };

print qq(

User Name:  
  

);

print end_html; 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cookies not set

[uma ramdoss]

hai all,
  
 i tested the folowing proxy.pl prg.
my browser displays cookies not set error. why
when it sends the request to the original server, it
sends connection :close header. why is it so.

Thanks

use strict;
use HTTP::Daemon;
use LWP::UserAgent;
use HTTP::Request;
my($CRLF)="\015\012";
my $d=new HTTP::Daemon
LocalAddr => 'localhost',

LocalPort => 8080;
Reuse=>1;
Listen=>20;

print "please contact me at\n ";

sub prefix {
  my $now = localtime;

  join "", map { "[$now] [${$}] $_\n" }
split /\n/, join "", @_;
}

$SIG{__WARN__} = sub { warn prefix @_ };
$SIG{__DIE__} = sub { die prefix @_ };
$SIG{CLD} = $SIG{CHLD} = sub { wait; };
my $agent=new LWP::UserAgent;
while (my $client= $d->accept)
{
   print "connected\n";
   defined (my $pid=fork);
   if ($pid)
   {
  undef($client);

   } else {
  $client->autoflush(1);
  &handler($client);
   }
}



sub handler
{
   my $client=shift;

  while($client)
   {
   my  $req = $client->get_request;
   print $req->url."\n";
   if (!defined $req){exit(0);}
   &fetchres($req,$client);
   }
}

sub fetchres
{
   my ($originreq)=shift;
   my $req=$originreq->clone;
   $req->protocol($originreq->protocol());
   my $res=$agent->request($req);
   chomp (my ($mess)=$res->message);
   my $client=shift;
   $client->send_status_line($res->code,$mess,
$res->protocol);
   print $client
$res->headers_as_string("$CRLF").("$CRLF");
   print $client ${$res->content_ref};

}


__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: shared cookies

[Wiggins d'Anconia]

Hytham Shehab wrote:
hi guys,
i have multiple domain names - etc multiple sites - that i would like to
share cookies inbetween, how can i - literally - do that, and is it enough
to use HTTP::Cookies !?
Mostly you can't, which is why I suppose the list has been so quiet. 
This is a security issue, you don't want other domains reading cookies 
that were specifically for your domain do you?  If you are talking sub 
domains, for instance having a cookie read from www.danconia.org, 
cgi.danconia.org, and mail.danconia.org is easily accomplished by 
specifiying the domain when setting the cookie. Otherwise you are 
probably going to have to do some redirection from a script at one 
domain to a script at the next, chaining on the value of the cookie and 
passing it through the query string (but for our sake (and yours) don't 
do that :-)).

http://danconia.org

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: shared cookies

[Todd Wade]

"Wiggins D'Anconia" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hytham Shehab wrote:
> > hi guys,
> > i have multiple domain names - etc multiple sites - that i would
like to
> > share cookies inbetween, how can i - literally - do that, and is it
enough
> > to use HTTP::Cookies !?
> >
>
> Mostly you can't, which is why I suppose the list has been so quiet.
> This is a security issue, you don't want other domains reading cookies
> that were specifically for your domain do you?  If you are talking sub


Microsoft has this thing called hta (hypertext applications, or something
like that) where you digitally sign your .asp file and give it a .hta
extension. Client side code can then work out of the sandbox (i.e. read
cookies from other domains). MS specific.

Todd W.



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookies and mod_perl

[Dennis Stout]

Is there any difference in setting cookies between operating under just
general CGI and when using an Apache webserver and mod_perl?

I got a program I'm writing that generates every page it dishes out on the
fly, dynamically.

If I can stay away from doing a use CGI;, I would love to.

Thanks,
Dennis


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Clearing cookies

[Wiggins d'Anconia]

Denzil Kruse wrote:
> Hi all,
> 
> I'm trying to clear a cookie using CGI::Cookies, and
> can't seem to do it :(
> 
> if ($clear_cookie eq 'yes') {
> 
>  my %cookies = fetch CGI::Cookie;
> 
>  print "getting cookie";
> 
>  if ($cookies{'id'}) {
> 
>   print "clearing cookie";
>   $cookies{'id'}->expires('-1s');
>   print "cleared cookie";
>  }
> }
> 
> I'm getting the "cleard cookie" message, but it is
> still there.
> 
> Denzil
> 

To clear the cookie in the user's client (browser) you have to "set" the
cookie again by printing it in the response headers. You are only
setting the local expiration, to have that maintained across the rest of
the session you have to tell the browser about it, which is done by
passing it back as if you were setting it initially.

HTH,

http://danconia.org

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: Clearing cookies

[Denzil Kruse]

--- Wiggins d'Anconia <[EMAIL PROTECTED]> wrote:

> Denzil Kruse wrote:
>

 
> To clear the cookie in the user's client (browser)
> you have to "set" the
> cookie again by printing it in the response headers.
> You are only
> setting the local expiration, to have that
> maintained across the rest of
> the session you have to tell the browser about it,
> which is done by
> passing it back as if you were setting it initially.
> 
> HTH,
> 
> http://danconia.org
> 

Okay, that makes sense.  Thanks for the help!

Denzil




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: Clearing cookies

[Denzil Kruse]

--- [EMAIL PROTECTED] wrote:

> can   you give a syntax example?

Here is a piece of what I'm doing:

if ($clear_cookie eq 'yes') {

 my %cookies = fetch CGI::Cookie;

 if ($cookies{'id'}) {

  $cookies{'id'}->expires('-1s');

  print "Set-Cookie: $cookies{'id'}\n";
 }
}
print "Content-type: text/html\n\n";
--

I'm just following the instructions at:

http://perldoc.perl.org/CGI/Cookie.html

This whole cookie thing is new to me.  Never wanted to
use them before because they were out of my control,
browsers might block them, or people might not
understand what they are and get all paranoid.  Or do
understand and get paranoid :o)

Denzil





Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: Clearing cookies

[Denzil Kruse]

I'm still having a problem clearing the cookie, or at
least with the browser realizing it has been cleared.

What happens is this:  The cookie is set, and my
program behaves as it is supposed to.  When I decide
to clear it, I do it and display a form which will
recreate the cookie once the form is filled out and
the submit button is pushed.

So it clears the cookie and displays the form.  I look
under C:\Documents and Settings\Owner\Cookies on my
local computet running the browser, and I see the
cookie disappear.  But when I press the button on the
form once, the browser behaves as if the cookie is
still set.  If I then press the button a second time,
it behaves as if the cookie isn't there (correctly).

I do have an apache rewrite rule in effect, maybe that
is causing it to have to do it twice?

Denzil




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: Clearing cookies

[Denzil Kruse]

Okay, never mind.  There was an error elsewhere in my
code.

Denzil

--- Denzil Kruse <[EMAIL PROTECTED]> wrote:

> I'm still having a problem clearing the cookie, or
> at
> least with the browser realizing it has been
> cleared.
> 
> What happens is this:  The cookie is set, and my
> program behaves as it is supposed to.  When I decide
> to clear it, I do it and display a form which will
> recreate the cookie once the form is filled out and
> the submit button is pushed.
> 
> So it clears the cookie and displays the form.  I
> look
> under C:\Documents and Settings\Owner\Cookies on my
> local computet running the browser, and I see the
> cookie disappear.  But when I press the button on
> the
> form once, the browser behaves as if the cookie is
> still set.  If I then press the button a second
> time,
> it behaves as if the cookie isn't there (correctly).
> 
> I do have an apache rewrite rule in effect, maybe
> that
> is causing it to have to do it twice?
> 
> Denzil
> 
> 
>   
> 
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
> 
> -- 
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> <http://learn.perl.org/>
> <http://learn.perl.org/first-response>
> 
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

RE: Retrieving cookies

[Scott Thompson]

> -Original Message-
> From: Stokes, John [mailto:[EMAIL PROTECTED]]
> Subject: Retrieving cookies
>
> I've figured out how to set a cookie, and I think I've retrieved it
> successfully (no errors, at least), but now how do I manipulate
> it? I can't
> figure out how to reference the cookie data.
>
> Here's an example of my code:
>
> use CGI;
> $q = new CGI();
> $myCookie = $q->cookie(-name=>'Fyre',
>-value=>test,
>-expires=>'+3M',
>-domain=>'.biola.edu');
> print $q->header(-cookie=>$myCookie);
>
> %cook = $q->cookie(-name=>'Fyre');
>

You can reference your cookie with:

$cook{'Fyre'};

++++
|| UNIREZ, Inc.Scott Thompson ||
++---+++
|| Address: 2555 Southwest Grapevine Parkway | Title: Programmer  ||
||  Suite 200| Phone: (817) 416-5800  ||
||  Grapevine, Texas 76051   | Extension: 104 ||
|| Fax: (817) 251-9199   | Cell:  (972) 342-5660  ||
|| Web: http://www.unirez.com/   | Email: [EMAIL PROTECTED]||
++===+++

Re: Retrieving cookies

[Curtis Poe]

--- "Stokes, John" <[EMAIL PROTECTED]> wrote:
> I've figured out how to set a cookie, and I think I've retrieved it
> successfully (no errors, at least), but now how do I manipulate it? I can't
> figure out how to reference the cookie data.
> 
> Here's an example of my code:
> 
> use CGI;
> $q = new CGI();
> $myCookie = $q->cookie(-name=>'Fyre',
>-value=>test,
>-expires=>'+3M',
>-domain=>'.biola.edu');
> print $q->header(-cookie=>$myCookie);
> %cook = $q->cookie(-name=>'Fyre'); 

First issue:  you do not appear to be using 'strict'.  I've had to maintain legacy 
code from
people who didn't use it and simple things like finding a misspelled variable name 
which should
have taken 2 seconds would wind up taking half an hour.  'use strict' is incredibly 
important. 
Here's a quick clean-up of that first code section:

#!/usr/bin/perl -wT
use strict;
use CGI;
my $q = CGI->new;

#note that the value of '-value' is now quoted.
my $myCookie = $q->cookie( -name=> 'Fyre',
   -value   => 'test',
   -expires => '+3M',
   -domain  => '.biola.edu');
print $q->header( -cookie => $myCookie );

The second issue:

> %cook = $q->cookie(-name=>'Fyre'); 

Generally, you cannot use CGI's 'cookie' method unless the cookie has been returned.  
That
requires that it be sent to the browser and then the browser issues a request for 
another resource
that accesses that cookie.  That *may* be the same script, but run twice (the first 
run sets it,
the second run retrieves it).

The cookie method will return a scalar representing the '-value' that is stored in the 
cookie:

my $cookie_value = $q->cookie( 'Fyre' );

If any of the above was not clear, send another message and I (or someone else) will 
explain in
more detail.

Cheers,
Curtis

=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: Retrieving cookies

[Stokes, John]

OK, I'm still having a problem.

I still can't seem to manipulate the cookie data. Say I want to record
someone's name and then print out "hello so-and-so" when they return to my
site. (That's not what this is actually for, but it's the same idea.) Why
doesn't the code below work on the second visit to the page?

It doesn't seem to work in an if() { structure either.

Thanks in advance.

use strict;
use CGI;
my $q = CGI->new;

#note that the value of '-value' is now 
quoted.
my $myCookie = $q->cookie( -name=> 'Fyre',
   
-value   => 'test',
   -expires => '+3M',
 
  -domain  => '.biola.edu');
print $q->header( -cookie => $myCookie );

my 
$cookie_value = $q->cookie( 'Fyre' );
print $cookie_value;

-John Stokes
[EMAIL PROTECTED] 

Three pillars: Humility, Communication, Balance

Re: Retrieving cookies

[Curtis Poe]

--- "Stokes, John" <[EMAIL PROTECTED]> wrote:
> OK, I'm still having a problem.
> 
> I still can't seem to manipulate the cookie data. Say I want to record
> someone's name and then print out "hello so-and-so" when they return to my
> site. (That's not what this is actually for, but it's the same idea.) Why
> doesn't the code below work on the second visit to the page?
> 
> It doesn't seem to work in an if() { structure either.
> 
> Thanks in advance.

When I posted the code, I left the domain in there as I assumed you were testing it on 
that
server.  If you are testing with a different domain, you can't retrieve the cookie 
(this is a
security measure to ensure that you can't read cookies set by other sites).

Removing the following should work:

-domain  => '.biola.edu'

I successfully ran the following code:

use strict;
use CGI;
my $q = CGI->new;

my $myCookie = $q->cookie( -name=> 'Fyre',
   -value   => 'blah,blah,blah',
   -expires => '+3M' );
my $cookie_value = $q->cookie( 'Fyre' );
print $q->header( -cookie => $myCookie ),
  $q->start_html,
  $q->p( "Test" );
if ( ! $cookie_value ) {
print $q->p( "No cookie passed" );
} else {
print $q->p( $cookie_value );
}
print $q->end_html;

Since domain is not specified, it should return the value (as it did for me).

When you don't specify the domain, it will default to your domain.

Cheers,
Curtis A. Poe

=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

RE: Retrieving cookies

[Stokes, John]

The code below does run, but it always returns a message of "No cookie
passed." I've refreshed the page, closed & reopened it & even quit my
browser & reaccessed. I never get any message but "No cookie passed"

I can look in the cookie list in IE's preferences, and the cookie is there.

Frustrated, but thankful for your help,

-John Stokes
Computer Psychiatrist (Director of Information Technology)
Church Resource Ministries
[EMAIL PROTECTED] 

Three pillars: Humility, Communication, Balance

> --
> From: Curtis Poe
> Reply To: [EMAIL PROTECTED]
> Sent: Friday, June 1, 2001 3:20 PM
> To:   CGI Beginners
> Subject:  Re: Retrieving cookies
> 
> --- "Stokes, John" <[EMAIL PROTECTED]> wrote:
> > OK, I'm still having a problem.
> > 
> > I still can't seem to manipulate the cookie data. Say I want to record
> > someone's name and then print out "hello so-and-so" when they return to
> my
> > site. (That's not what this is actually for, but it's the same idea.)
> Why
> > doesn't the code below work on the second visit to the page?
> > 
> > It doesn't seem to work in an if() { structure either.
> > 
> > Thanks in advance.
> 
> When I posted the code, I left the domain in there as I assumed you were
> testing it on that
> server.  If you are testing with a different domain, you can't retrieve
> the cookie (this is a
> security measure to ensure that you can't read cookies set by other
> sites).
> 
> Removing the following should work:
> 
> -domain  => '.biola.edu'
> 
> I successfully ran the following code:
> 
> use strict;
> use CGI;
> my $q = CGI->new;
> 
> my $myCookie = $q->cookie( -name=> 'Fyre',
>-value   => 'blah,blah,blah',
>-expires => '+3M' );
> my $cookie_value = $q->cookie( 'Fyre' );
> print $q->header( -cookie => $myCookie ),
> $q->start_html,
> $q->p( "Test" );
> if ( ! $cookie_value ) {
>   print $q->p( "No cookie passed" );
> } else {
>   print $q->p( $cookie_value );
> }
>   print $q->end_html;
> 
> Since domain is not specified, it should return the value (as it did for
> me).
> 
> When you don't specify the domain, it will default to your domain.
> 
> Cheers,
> Curtis A. Poe
> 
> =
> Senior Programmer
> Onsite! Technology (http://www.onsitetech.com/)
> "Ovid" on http://www.perlmonks.org/
> 
> __
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35 
> a year!  http://personal.mail.yahoo.com/
> 
> 

Re: COOKIES AGAIN...

[Curtis Poe]

--- Nigel Wetters <[EMAIL PROTECTED]> wrote:
> One of our partners ran into a problem with load balancing on IIS. Each server set a 
>session
> cookie, which eventually pushed the useful cookies out of the browser's store. Yet 
>another
> reason why IIS isn't ready for enterprise-level solutions.

While I definitely have some issues with IIS, this isn't one of them.  There is a 
domain limit to
cookies (20, I think) and a total limit (300, as I recall) that a browser is required 
to store,
according to standards.  While the browser may exceed those limits, it is in no way 
required to do
so.  If a particular site or application is having problems with too many cookies, 
it's due to
that site or domain poorly managing cookies and setting too many of them, not the 
necessarily the
Web server.

IIS does not set the cookies, so it's not to blame.  ASP might set them, with its 
session managing
tools, but that's still a configuration or programming issue and not a problem with 
IIS.

As for my issues with IIS, I am sick of having to switch to NPH scripts because it 
mangles headers
when setting cookies and doing a simultaneous redirect.  This bug has been in IIS for 
the LAST 3
VERSIONS!!!  You would think that MS would get it right after a while...

Cheers,
Curtis Poe

=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookies and Security

[Ryan Davis]

Hey all,

I have a password protected area, and after the user puts in their password, I store 
it in a cookie, and the CGI reads that cookie every time to determine if the user is 
logged in or not.  I figured this was safer than passing a 'loggedin' param as a 
hidden field, but I'm not sure if there is an industry standard way to do this.  My 
code is too long (300+ lines, and messy), so here's the outline/psuedocode:


#try to snag the cookie
$pw = get_cookie()

#if the user is logging in for the first time, write the cookie
if($cgi->param("password"){
$pw = $cgi->param("password");
write_cookie($pw);
}

#set a boolean if the password is correct
$loggedIn = isCorrect($pw);

unless($loggedIn){
prompt_for_password();
}elsif(
...rest of program


Is this secure?  Is there a better way to do this?

Thanks,
Ryan

Cookies stopped working

[Kirk W. Batzer]

I'm attempting to port a perl CGI application
from:  "perl, 5.005_02 built for 3446-svr4.0"
to:"perl, v5.6.1 built for sun4-solaris"

The application uses "cookies" to maintain "state" information.  The
following code is successfully creating and using cookies in the perl
5.5 , but failing to create cookies in the perl 5.6 environment.

==
use CGI qw(:standard);
use MIME::Base64;
..
%mylist = &SelectFromTable(*table, *collist, *wherelist);

local(@userinfo) = ($mylist{userid},
$mylist{usertype},
$mylist{username},
$mylist{phone},
$mylist{groupname},
$mylist{email});

local($user) = encode_base64( join(":", @userinfo) );

$cookie = cookie(   -name=>'loginfo',
-value=>$user,
);
print header(-cookie=>$cookie);

===

I've noticed the CGI.pm docs show a true reference when creating and
fetching cookies.  I'm wondering if this is contributing to this
problem?  The above code seems to use an anonymous reference where the
docs example, below use a true reference "$query".

>From CGI.PM docs:
use CGI;
$query = new CGI;
$cookie=$query->cookie( -name=>'family information',
-value=>\%childrens_ages
);


I'm not the perl CGI-cookie expert.  I'm attempting to learn more by
porting this code.  Any help would be appreciated.

Kirk




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

web and cookies

[zaka rias]

i got a script in my web like this :

$a=$ENV{REMOTE_ADDR}'
open(infi, ">>iplog.txt">;
print infi "$a \n";
close infi;
...
another process

that script i put in main.html
if some users come into my site, that script will
catch the user ip and write it to iplog.txt file, and
then im using that iplog.txt for hit counter purpose.

but that's not accurate, cuz everytime user click
main.html the hit counter growing bigger and bigger.
and then i heard about cookies, and i heard that with
cookies, we (as a web server/server) will recognize
guest (user/visitor), is that right ? 



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Info Cookies

[Bob Showalter]

> -Original Message-
> From: alex.tesi [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 08, 2001 9:03 AM
> To: [EMAIL PROTECTED]
> Subject: Info Cookies
> 
> 
> Hi
> i'd like to make a cookies and read that cookies from al page 
> of my site.
> Any of you can help me?

Assuming there's a Perl question in there somewhere, start by
reading

   perldoc CGI

look for the section titled "HTTP COOKIES", which tells you how
to create, store, and retrieve cookies.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Info Cookies

[Gary Stainburn]

This script shows how to set a cookie manually, and then dump the environment 
to show it..  The cookie will automatically be made available to anyone 
accessing any document under the specified path '/' on my domain 
'ringways.co.uk'. 

In Perl, you read the cookies from $ENV{HTTP_COOKIE}

No doubt, CGI.pm will do all this for you too.

Gary

#!/usr/bin/perl -w

print <hello
hello
  
Label
Value
  
EOF
while (($KEY,$VALUE) = each(%ENV)) {
  $VALUE='<empty>' if (!$VALUE);
  print "
  
$KEY
$VALUE
  
";
}
@keywords=$query->param;
foreach $keyword (@keywords) {
  $VALUE=$query->param($keyword);
  $VALUE='<empty>' if (!$VALUE);
  print "

  # $keyword
  $VALUE

";
}
print <


EOF
exit;


On Monday 08 October 2001 2:03 pm, alex.tesi wrote:
> Hi
> i'd like to make a cookies and read that cookies from al page of my site.
> Any of you can help me?
>
> Thankyou by AlexTesi

-- 
Gary Stainburn
 
This email does not contain private or confidential material as it
may be snooped on by interested government parties for unknown
and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

apache localhost cookies

[Carl Franks]

In short, I'm using a perl script to set a cookie, and Netscape Navigator 
isn't seeing it.

It sets cookies o.k. on a '.com' webserver, but not on my localhost.

I'm running RedHat 7.2 with apache installed.

Viewing http://localhost in Netscape works, as does running scripts at
http://localhost/cgi-bin/script.cgi

I'm using a perl script (use CGI) to send a cookie.
Netscape Navigator is set to accept all cookies, but after viewing the
script that sets the cookie, testing for cookies is negative.

In the script,
the cookie domain is set to ".localhost"
the cookie path is set to "/cgi-bin"
the cookie expires is set to "+15m"
name and value are set.

When I run the perl script from the command line, the header that's printed
appears o.k.

I can't find any applicable info in the apache FAQ, so any pointers would be
much appreciated.

Thank-you,
Carl Franks

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookies and SSI

[Robert Howard]

If a script is being called as a Server Side Include, is it still possible
to set and read cookies from within the script? Problem I am running into is
that the header of the main html is read before my script, so no cookies are
set by using print header (-cookie => $session_cookie).

R.A. Howard


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Session cookies

[eric-perl]

On Wed, 27 Feb 2002, Octavian Rasnita wrote:
> I want to set a cookie in a Perl script only for the current session, and I
> don't need that cookie after the visitor closes the browser.
> 
> Can I use this kind of cookie if the user has deactivated cookies in her
> browser?
> 
> I can't test this on my localhost, because even if I disable the cookies,
> they are set with no problem.

Octavian:

Again, I recommend that you read Linconln Stien's excellent book 
"The Definitive Guide to Using CGI.pm". (Setting cookies that expire at 
the end of the user's session only requires not setting any expiration 
date.)

-- 
Eric P.
Los Gatos, CA


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirect and cookies

[zentara]

On Fri, 30 Aug 2002 11:01:08 +0200, [EMAIL PROTECTED] (Alex Agerholm)
wrote:

>Hi all,
>
>I have a problem with redirect.
>I have made a login system and when the user has logged in correctly I set a
>cookie and redirects the user to the first page.
>But on all pages (including the first one) I make a check to see if the user
>is logged in based on the cookie.
>
>When I redirect from the login page to the first page I therefore need to
>give the cookie along like:  redirect( -uri=>xxx.cgi, -cookie=>$cookie);
>BUT IT DOES NOT WORK - my xxx.cgi script does not get the cookie.
>What can I do to fix this ?

Have you checked that the cookie is actually being set in the browser?
Then what code are you using to retreive the cookie?




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Redirect and cookies

[Bob Showalter]

> -Original Message-
> From: Alex Agerholm [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 30, 2002 5:01 AM
> To: [EMAIL PROTECTED]
> Subject: Redirect and cookies
> 
> 
> Hi all,
> 
> I have a problem with redirect.
> I have made a login system and when the user has logged in 
> correctly I set a
> cookie and redirects the user to the first page.
> But on all pages (including the first one) I make a check to 
> see if the user
> is logged in based on the cookie.
> 
> When I redirect from the login page to the first page I 
> therefore need to
> give the cookie along like:  redirect( -uri=>xxx.cgi, 
> -cookie=>$cookie);
> BUT IT DOES NOT WORK - my xxx.cgi script does not get the cookie.
> What can I do to fix this ?

Try using a "full" URL, e.g. -url => http://myserver/cgi-bin/xxx.cgi

The "relative" URL may be triggering an internal redirect, which would not
pass the cookie.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirect and cookies

[Gfoo]

[EMAIL PROTECTED] (Alex Agerholm) wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]: 

> ...
> When I redirect from the login page to the first page I therefore need
> to give the cookie along like:  redirect( -uri=>xxx.cgi,
> -cookie=>$cookie); BUT IT DOES NOT WORK - my xxx.cgi script does not
> get the cookie. What can I do to fix this ?
> 
> Regards
> Alex
> 

Are you sure your client is configured to accept cookies?
If not, you could give user an informative message about that, and start 
using the URL (since the cookies are disabled).

GFoo


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Redirect and cookies

[Ovid]

> I have made a login system and when the user has logged in correctly I set a
> cookie and redirects the user to the first page.
> But on all pages (including the first one) I make a check to see if the user
> is logged in based on the cookie.
> 
> When I redirect from the login page to the first page I therefore need to
> give the cookie along like:  redirect( -uri=>xxx.cgi, -cookie=>$cookie);
> BUT IT DOES NOT WORK - my xxx.cgi script does not get the cookie.
> What can I do to fix this ?

Hi Alex,

Is there any chance that you are on IIS?  IIS has had a long-standing bug in version 
3.0, 4.0, and
5.0 where you cannot set a cookie and do a redirect at the same time unless you switch 
to
non-parsed header scripts.

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q176113

Cheers,
Curtis "Ovid" Poe

=
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A

__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Redirect and cookies

[Alex Agerholm]

Hi Curtis,

Thanks for your help, I am actually on IIS so you have saved me a lot of
troubles.
Do you know how to work around this ?
>From the microsoft article below it seems like running in nph mode should
solve it but redirect(-uri => xxx.cgi, -cookie => $cookie, -nph => 1) does
not solve it and neither does using the -nph pragma in the the use CGI line.

Regards
Alex

-Original Message-
From: Ovid [mailto:[EMAIL PROTECTED]]
Sent: 1. september 2002 03:17
To: Alex Agerholm; [EMAIL PROTECTED]
Subject: Re: Redirect and cookies


> I have made a login system and when the user has logged in correctly I set
a
> cookie and redirects the user to the first page.
> But on all pages (including the first one) I make a check to see if the
user
> is logged in based on the cookie.
>
> When I redirect from the login page to the first page I therefore need to
> give the cookie along like:  redirect( -uri=>xxx.cgi, -cookie=>$cookie);
> BUT IT DOES NOT WORK - my xxx.cgi script does not get the cookie.
> What can I do to fix this ?

Hi Alex,

Is there any chance that you are on IIS?  IIS has had a long-standing bug in
version 3.0, 4.0, and
5.0 where you cannot set a cookie and do a redirect at the same time unless
you switch to
non-parsed header scripts.

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q176113

Cheers,
Curtis "Ovid" Poe

=
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A

__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Redirect and cookies

[Ovid]

--- Alex Agerholm <[EMAIL PROTECTED]> wrote:
> Hi Curtis,
> 
> Thanks for your help, I am actually on IIS so you have saved me a lot of
> troubles.
> Do you know how to work around this ?
> >From the microsoft article below it seems like running in nph mode should
> solve it but redirect(-uri => xxx.cgi, -cookie => $cookie, -nph => 1) does
> not solve it and neither does using the -nph pragma in the the use CGI line.
> 
> Regards
> Alex

Alex,

I would telnet to port 80 and manually request the data from your script.  That way, 
you can see
the headers that are being sent.  Or, you could just write a short LWP script to do 
this (see
perldoc LWP).  Yet another option is to simply run the script from the command line 
(while running
as -noh), but this has the problem that you can't see if your script is doing anything 
odd.

Also, just to make sure you're handling it correcty, with IIS, the script name must 
begin with
"nph-".

Cheers,
Curtis "Ovid" Poe

=
"Ovid" on http://www.perlmonks.org/
Someone asked me how to count to 10 in Perl:
push@A,$_ for reverse q.e...q.n.;for(@A){$_=unpack(q|c|,$_);@a=split//;
shift@a;shift@a if $a[$[]eq$[;$_=join q||,@a};print $_,$/for reverse @A

__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Sending and Reading cookies

[Jerry Lawson]

I'm having trouble sending a cookie. The book I have says to send a
cookie the code 'print "Set-Cookie:name=value\n";' will work. When I
implement this code in my script, the cookie is not being set. Can
someone tell me what I am doing wrong?

Thanks,

Jerry Lawson




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookies and IP Addresses

[Mike Craig]

Hi all,
Can you help me with this?

I want to get the servers IP address and the IP address of the referrer. Is
there a reliable way to do this? When I used 'REMOTE_ADDR' I get different
values even when I go directly to my site and then call 'REMOTE_ADDR'. Does
anyone know why? I want to use the IP address to ensure that some of the
code is only called from my site or from a valid IP address. I want the IP
address and not the URL so I can convert it into Hex.

$ENV{'SERVER_NAME'};
$ENV{'HTTP_REFERER'};
$ENV{'REMOTE_ADDR'};


In the discussions on cookies does any one know why when I set a cookie and
restart some time later my cookies are lost when I do the following in
JavaScript

var cookieDate = new Date()
cookieDate.setTime(cookieDate.getTime() + 10 * 365 * 24 * 3600 * 1000);//Add
10 years

document.cookie = escape("MyCookie=XXX" + ";expires=" +
cookieDate.toGMTString() + ";domain=.UltraTextPro.biz");

Mike


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help with Cookies

[CraigD]

This is how I did it.
if ( @loginfo = CGI::cookie('mspplog') ) {
$user_name = $loginfo[0];
$password = $loginfo[1];
$checkPassword = 'true';
}
On Friday 07 February 2003 08:07 am, Kipp, James wrote:
> > All am I am trying to do now is have a user enter his/her
> > name in a form and have that saved to a cookie, so when they
> > return, they will get something like " Your juser, please
> > proceed" . I took the example here:
> > http://stein.cshl.org/WWW/CGI/examples/cookie.cgi
> >
> > Below is the code I am working with.  But when I return to
> > the page I just get the form again. What am i missing. Sorry
> > if this is obvious, but i am not getting it and I have read
> > the tutorial and the RFC on http state (thanks John ).
>
> I revised the code to get rid of the obvious mistakes. I can see that the
> cookie is made, but how can get it to print the user after it reads that
> there is indeed a a cookie.
> here is what i have now:
> ---
> use CGI qw(:standard);
> # get cookie if it is there
> %all = cookie('user');
> # Recover the new users from the form parameter 'new_user'
> $new = param('new_user');
>
> # Add  the user submitted in the form as the new cookie
> $cookie = cookie(-name=>'user',
>-value=>$new,
>-expires=>'+1h');
>
> # Print the header, incorporating the cookie and the expiration date...
> print header(-cookie=>$cookie);
> # Now we're ready to create our HTML page.
> print start_html('Test cookie');
>
> if (%all) {   # shouldn't it print if there is a cookie
> found??
>   foreach $key ( keys %all) {
>   print "$all{$key}";
> }
> }
> else { print " NO USERS SAVED " };
>
> print qq(
> 
> User Name:  
>   
> 
> );
>
> print end_html;

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cookies not set

[drieux]

On Sunday, Feb 16, 2003, at 21:54 US/Pacific, uma ramdoss wrote:
[..]

 why
when it sends the request to the original server, it
sends connection :close header. why is it so.

[..]

I think that is the 'default' - unless you
expressly ask for

	Connection: keep-alive

to request that the connection be kept alive
between calls to the web server. But even still
the server is not required to keep that socket
connection alive.

ciao
drieux

---


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and mod_perl

[Wiggins d'Anconia]

Dennis Stout wrote:
Is there any difference in setting cookies between operating under just
general CGI and when using an Apache webserver and mod_perl?
I got a program I'm writing that generates every page it dishes out on the
fly, dynamically.
If I can stay away from doing a use CGI;, I would love to.

Since cookies are interpreted by the client and read from the header 
before the content type is set there should be no difference, with the 
exception of when you have opportunities to print the header under 
mod_perl, aka because you could print the header in an early part of the 
response and then handle content later or something similar, you would 
just have to make sure you are printing the cookies as part of the header.

http://danconia.org

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and mod_perl

[Bob Showalter]

Dennis Stout wrote:
> Is there any difference in setting cookies between operating under
> just general CGI and when using an Apache webserver and mod_perl?

By "general CGI", if you mean mod_cgi, then no, there is no difference.

>
> I got a program I'm writing that generates every page it dishes out
> on the fly, dynamically.
>
> If I can stay away from doing a use CGI;, I would love to.

The CGI.pm module and mod_perl are not mutally exclusive. You can use CGI
when running under mod_perl. Why do you want to stay away from it?

Are you running your scripts under Apache::Registry?




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cookies and character sets

[Andrew Brosnan]

After months of trouble free operation, a shopping cart I wrote is
having cookie trouble with browsers in Israel. I'm setting cookies using
CGI.pm in the standard way.

I'm assuming that folks in Israel may not use iso-8859-1. Has anyone had
problems with cookies not being read when encountering different
character sets?

Other ideas?

Regards,

Andrew

-- 
Andrew Brosnan - Broscom LLC - 1 603 447 6000
[EMAIL PROTECTED] - http://www.broscom.com
Websites, Hosting, Programming, Consulting

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Cookies v. Hiddent Fields

[Siegfried Heintze]

What is the difference (as far as security goes) between using a cookie and
a hidden field? Are hidden fields cached if we are using SSL? I think not. 

 

If I use a GUID as a session ID in my database and store the GUID in a
hidden field and the user sees the GUID in some GET parameters, is this of
any consequence? 

 

Someone recommend that I don't persist cookies. How do I not persist
cookies?

 

  Thanks,

  Siegfried

 

cookies as hidden files

[Denzil Kruse]

Hi all,

I read through the docs for CGI::Cookie and learned
how to set a cookie.  I do it with line:

my $cookie = new CGI::Cookie(-name=>'name',
 -value=>"$name",
 -expires=>'+6M');

But, I've found out that when IE creates the cookie,
it creates it as a hidden file, so when I come around
and fetch it, it can't find the cookie and hangs.

But, I saw some cookies that weren't hidden.  The list
just got bigger once I told windows to how hidden
files.  

So, my question is, how can I create the cookie in
such a way that it isn't hidden?  I couldn't find it
in the docs I looked through.

thanks,
Denzil



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Fwd: Re: Retrieving cookies

[Curtis Poe]

I forgot to mention something:  the first time you access the script through your 
browser, it
won't have the cookie (since this is the first time it's being set).  The second time 
you access
it, the browser will return the cookie value and the script will display it.

> use strict;
> use CGI;
> my $q = CGI->new;
> 
> my $myCookie = $q->cookie( -name=> 'Fyre',
>-value   => 'blah,blah,blah',
>-expires => '+3M' );
> my $cookie_value = $q->cookie( 'Fyre' );
> print $q->header( -cookie => $myCookie ),
> $q->start_html,
> $q->p( "Test" );
> if ( ! $cookie_value ) {
>   print $q->p( "No cookie passed" );
> } else {
>   print $q->p( $cookie_value );
> }
>   print $q->end_html;


=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Redirecting AND creating cookies

[Mark Mogridge]

Ooops I¹ll try again...with a header this time.


Hi there!

Redirecting AND creating cookies - I can't!

I can create cookies...
print header(-cookie=>[$clubid,$membername,$pointsbal]);
That¹s fine



I can redirect...  
print "Location: $gotourl";
   
OR
   
print redirect("$gotourl");
That¹s fine ­ 

but NOT if I create cookies first.  The location gets sent to the browser
window instead.
Some documentation has vaguely mentioned that I may have my header in the
wrong place.
Should I Œclose¹/¹end¹ the first (cookies) print header before continuing?


I tried putting the two together as in ...
print header(-cookie=>[$clubid,$membername,$pointsbal] ,
redirect($gotourl));
It almost worked ­ but the url came out in CAPS so it wasn¹t recognised by
the browser.


Maybe I¹m too tired to see it ­ but I just can¹t!

Yours, Mark. 

Re: Cookies and Security

[Roger C Haslock]

Your script will be multiply concurrent, will it not? That is, several users
may be executing the same [instance of the] script. How are you going to
tell them apart?

I know CGI.pm retains values from a previous invocation, but have never
understood how to differentiate between the separate users of the script. I
look with interest to the more learned answers to your query.

- Roger -

- Original Message -
From: "Ryan Davis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 10:00 AM
Subject: Cookies and Security


Hey all,

I have a password protected area, and after the user puts in their password,
I store it in a cookie, and the CGI reads that cookie every time to
determine if the user is logged in or not.  I figured this was safer than
passing a 'loggedin' param as a hidden field, but I'm not sure if there is
an industry standard way to do this.  My code is too long (300+ lines, and
messy), so here's the outline/psuedocode:


#try to snag the cookie
$pw = get_cookie()

#if the user is logging in for the first time, write the cookie
if($cgi->param("password"){
$pw = $cgi->param("password");
write_cookie($pw);
}

#set a boolean if the password is correct
$loggedIn = isCorrect($pw);

unless($loggedIn){
prompt_for_password();
}elsif(
...rest of program


Is this secure?  Is there a better way to do this?

Thanks,
Ryan



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and Security

[Curtis Poe]

--- Ryan Davis <[EMAIL PROTECTED]> wrote:
> Hey all,
> 
> I have a password protected area, and after the user puts in their password, I store 
>it in a
> cookie, and the CGI reads that cookie every time to determine if the user is logged 
>in or not. 
> I figured this was safer than passing a 'loggedin' param as a hidden field, but I'm 
>not sure if
> there is an industry standard way to do this.  My code is too long (300+ lines, and 
>messy), so
> here's the outline/psuedocode:
> 
> 
> #try to snag the cookie
> $pw = get_cookie()
> 
> #if the user is logging in for the first time, write the cookie
> if($cgi->param("password"){
> $pw = $cgi->param("password");
> write_cookie($pw);
> }
> 
> #set a boolean if the password is correct
> $loggedIn = isCorrect($pw);
> 
> unless($loggedIn){
> prompt_for_password();
> }elsif(
> ...rest of program
> 
> 
> Is this secure?  Is there a better way to do this?
> 
> Thanks,
> Ryan

Ryan,

Storing passwords in cookies is very insecure.  There are often a number of ways to 
get to the
data in a cookie.  Running a packet sniffer is one.  Some sites allow users to sign up 
and post
information to the site.  These pages often have user-supplied javascript and that can 
be used to
grab cookies.

A better way of handling this is to create a *digest* of the password.  With this 
method, you
create a string of characters that can be computed from the password, but the password 
cannot be
computed from the characters.  It is mathematically very unlikely that two different 
passwords
will ever generate the same digest (much less likely than two people choosing the same 
password.

Here's a subroutine that will do what you need.  It creates a 22 character digest from 
a password.
 I've taken this from one of my programs and modified it for you.  It's pretty much 
cut-n-paste
into your code (which is why it's not the most efficient way of doing this).

sub create_digest_from_password {
my $pass = shift;

use Digest::MD5;
my $md5 = new Digest::MD5;

my $rand = '%doM4)#-<';

$md5->add( $pass );
$md5->add( $rand );
return $md5->b64digest;
}

Note the $rand variable.  What this is for is to add a completely random string to the 
password. 
That way, if someone figures out that you're using md5, they can't just "brute force" 
the password
by guessing at the password.  They'd also have to figure out the random string.

Also, in my actual code (which is a bit more complex than what you see here), I DO NOT 
HAVE $rand
HARD-CODED IN THE PROGRAM  This is a biggy.  If someone gets your source code, all 
bets are
off.  What I do is put the value of $rand in a file in a non-Web accessible directory 
and have my
program read it in.  That way, it's never explicitly in the code.

Incidentally, our databases also do not have passwords in them.  We use a technique 
similar to
what's above.  If, for some reason, we were to lose the $rand, we wouldn't be able to 
verify any
passwords.  It's an inconvenience, but security and convenience are mutually exclusive.

Cheers,
Curtis Poe

=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and Security

[Ryan Davis]

First of all, thanks for the quick response.  This application isn't in use
yet, so now is the time to make security changes

A few questions/let me see if I'm following you:

A user enters their password, I create the digest, and store the digest as a
cookie.  This is secure since you can't recreate the digest without knowing
$rand.

When they change pages (states in the script) the CGI reads the cookie, and
converts the digest to password, and verifies it?

How is the conversion from digest to password done?  I check my docs, and it
doesn't say anything about getting the message _out_ of digest form.

Thanks,
Ryan



- Original Message -
From: Curtis Poe <[EMAIL PROTECTED]>
To: CGI Beginners <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 11:00 AM
Subject: Re: Cookies and Security


> --- Ryan Davis <[EMAIL PROTECTED]> wrote:
> > Hey all,
> >
> > I have a password protected area, and after the user puts in their
password, I store it in a
> > cookie, and the CGI reads that cookie every time to determine if the
user is logged in or not.
> > I figured this was safer than passing a 'loggedin' param as a hidden
field, but I'm not sure if
> > there is an industry standard way to do this.  My code is too long (300+
lines, and messy), so
> > here's the outline/psuedocode:
> >
> >
> > #try to snag the cookie
> > $pw = get_cookie()
> >
> > #if the user is logging in for the first time, write the cookie
> > if($cgi->param("password"){
> > $pw = $cgi->param("password");
> > write_cookie($pw);
> > }
> >
> > #set a boolean if the password is correct
> > $loggedIn = isCorrect($pw);
> >
> > unless($loggedIn){
> > prompt_for_password();
> > }elsif(
> > ...rest of program
> >
> >
> > Is this secure?  Is there a better way to do this?
> >
> > Thanks,
> > Ryan
>
> Ryan,
>
> Storing passwords in cookies is very insecure.  There are often a number
of ways to get to the
> data in a cookie.  Running a packet sniffer is one.  Some sites allow
users to sign up and post
> information to the site.  These pages often have user-supplied javascript
and that can be used to
> grab cookies.
>
> A better way of handling this is to create a *digest* of the password.
With this method, you
> create a string of characters that can be computed from the password, but
the password cannot be
> computed from the characters.  It is mathematically very unlikely that two
different passwords
> will ever generate the same digest (much less likely than two people
choosing the same password.
>
> Here's a subroutine that will do what you need.  It creates a 22 character
digest from a password.
>  I've taken this from one of my programs and modified it for you.  It's
pretty much cut-n-paste
> into your code (which is why it's not the most efficient way of doing
this).
>
> sub create_digest_from_password {
> my $pass = shift;
>
> use Digest::MD5;
> my $md5 = new Digest::MD5;
>
> my $rand = '%doM4)#-<';
>
> $md5->add( $pass );
> $md5->add( $rand );
> return $md5->b64digest;
> }
>
> Note the $rand variable.  What this is for is to add a completely random
string to the password.
> That way, if someone figures out that you're using md5, they can't just
"brute force" the password
> by guessing at the password.  They'd also have to figure out the random
string.
>
> Also, in my actual code (which is a bit more complex than what you see
here), I DO NOT HAVE $rand
> HARD-CODED IN THE PROGRAM  This is a biggy.  If someone gets your
source code, all bets are
> off.  What I do is put the value of $rand in a file in a non-Web
accessible directory and have my
> program read it in.  That way, it's never explicitly in the code.
>
> Incidentally, our databases also do not have passwords in them.  We use a
technique similar to
> what's above.  If, for some reason, we were to lose the $rand, we wouldn't
be able to verify any
> passwords.  It's an inconvenience, but security and convenience are
mutually exclusive.
>
> Cheers,
> Curtis Poe
>
> =
> Senior Programmer
> Onsite! Technology (http://www.onsitetech.com/)
> "Ovid" on http://www.perlmonks.org/
>
> __
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and Security

[Matt Kent]

Ryan Davis wrote:
> 
> First of all, thanks for the quick response.  This application isn't in use
> yet, so now is the time to make security changes
> 
> A few questions/let me see if I'm following you:
> 
> A user enters their password, I create the digest, and store the digest as a
> cookie.  This is secure since you can't recreate the digest without knowing
> $rand.
> 
> When they change pages (states in the script) the CGI reads the cookie, and
> converts the digest to password, and verifies it?
> 
> How is the conversion from digest to password done?  I check my docs, and it
> doesn't say anything about getting the message _out_ of digest form.
> 
> Thanks,
> Ryan
> 
What you do is take the password on the system and digest it again.
Then do the compare.

Or at least that's what I remember from reading the security section of "CGI
Programming with Perl", though I may be wrong.

Matt

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and Security

[Curtis Poe]

--- Ryan Davis <[EMAIL PROTECTED]> wrote:
> First of all, thanks for the quick response.  This application isn't in use
> yet, so now is the time to make security changes
> 
> A few questions/let me see if I'm following you:
> 
> A user enters their password, I create the digest, and store the digest as a
> cookie.  This is secure since you can't recreate the digest without knowing
> $rand.
> 
> When they change pages (states in the script) the CGI reads the cookie, and
> converts the digest to password, and verifies it?
> 
> How is the conversion from digest to password done?  I check my docs, and it
> doesn't say anything about getting the message _out_ of digest form.
> 
> Thanks,
> Ryan

Ryan,

It is mathematically improbable that you can convert from the digest to the password.  
That is why
digests are often used to store passwords.  If a cracker breaks into your box and 
snags a list of
'digested' passwords, they can't recover the passwords.  In short, you *can't* get the 
message out
of digest form.

Here's how it works:  you have a new user sign up and you issue them a user name and 
password. 
Then, you have your digest creation function that I gave you create a digest from the 
password. 
You save this digest in the database or flat file or whatever.  You *never* save the 
password. 
Later, when they log in, you recreate a digest from the password using the *exact* 
same digest
creation function.  Then, you compare the computed digest with what's in the database. 
 If they
match, the user is good and you can send the digest in the cookie.  Later, when you 
retrieve the
cookie, you just compare its value to what's in the database (no need to recompute).

The important thing to remember is that whenever a digest is created from a password, 
the function
NEVER CHANGES.  I would put the "create_digest_from_password" function in a module so 
that all
scripts are guaranteed to access the same function.

If you're looking for a more sophisticated version of this, you can read
http://www.perlmonks.org/index.pl?node_id=101247.  In this post, I was asking about 
advice on a
security model I was developing.  It's object-oriented Perl and some of it may be 
confusing, but
if you read through it you can see the framework of a session-oriented authentication 
system.  If
you're new to Perl, though, it might be a bit confusing.

Cheers,
Curtis Poe

=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cookies and Security

[Joel Hughes]

Curtis,
are you sure that sending the digest back to the client in cookie form is a
good idea?

I mean, if I were a hacker, could I not register and then retrieve the
digest - you then have the plain text and the cipher text. (admittedly you
would have to know that whats in your cookie is a digest rather than another
form of session id but stilll...)

I'm not sure how easy it is then discover which algorithm is used when you
have the plain & cipher but, seeing as MD5, is fairly popular - that might
be a good starting point for the hacker to mount an assault on discovering
the function.

joel

-Original Message-
From: Curtis Poe [mailto:[EMAIL PROTECTED]]
Sent: 08 August 2001 17:38
To: CGI Beginners
Subject: Re: Cookies and Security


--- Ryan Davis <[EMAIL PROTECTED]> wrote:
> First of all, thanks for the quick response.  This application isn't in
use
> yet, so now is the time to make security changes
>
> A few questions/let me see if I'm following you:
>
> A user enters their password, I create the digest, and store the digest as
a
> cookie.  This is secure since you can't recreate the digest without
knowing
> $rand.
>
> When they change pages (states in the script) the CGI reads the cookie,
and
> converts the digest to password, and verifies it?
>
> How is the conversion from digest to password done?  I check my docs, and
it
> doesn't say anything about getting the message _out_ of digest form.
>
> Thanks,
> Ryan

Ryan,

It is mathematically improbable that you can convert from the digest to the
password.  That is why
digests are often used to store passwords.  If a cracker breaks into your
box and snags a list of
'digested' passwords, they can't recover the passwords.  In short, you
*can't* get the message out
of digest form.

Here's how it works:  you have a new user sign up and you issue them a user
name and password.
Then, you have your digest creation function that I gave you create a digest
from the password.
You save this digest in the database or flat file or whatever.  You *never*
save the password.
Later, when they log in, you recreate a digest from the password using the
*exact* same digest
creation function.  Then, you compare the computed digest with what's in the
database.  If they
match, the user is good and you can send the digest in the cookie.  Later,
when you retrieve the
cookie, you just compare its value to what's in the database (no need to
recompute).

The important thing to remember is that whenever a digest is created from a
password, the function
NEVER CHANGES.  I would put the "create_digest_from_password" function in a
module so that all
scripts are guaranteed to access the same function.

If you're looking for a more sophisticated version of this, you can read
http://www.perlmonks.org/index.pl?node_id=101247.  In this post, I was
asking about advice on a
security model I was developing.  It's object-oriented Perl and some of it
may be confusing, but
if you read through it you can see the framework of a session-oriented
authentication system.  If
you're new to Perl, though, it might be a bit confusing.

Cheers,
Curtis Poe

=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Cookies and Security

[Curtis Poe]

--- Joel Hughes <[EMAIL PROTECTED]> wrote:
> Curtis,
> are you sure that sending the digest back to the client in cookie form is a
> good idea?
> 
> I mean, if I were a hacker, could I not register and then retrieve the
> digest - you then have the plain text and the cipher text. (admittedly you
> would have to know that whats in your cookie is a digest rather than another
> form of session id but stilll...)
> 
> I'm not sure how easy it is then discover which algorithm is used when you
> have the plain & cipher but, seeing as MD5, is fairly popular - that might
> be a good starting point for the hacker to mount an assault on discovering
> the function.
> 
> joel

Joel,

That's a good question.  The idea here is that the best security protocols should have 
their
details openly available to anyone and still be relatively hard to crack.  The 
solution is
suggested, while not the best, is still relatively secure if implemented properly.  
However, if
you're protecting banking information or medical records, I'd opt for an even more 
secure
mechanism.

Regarding your concerns, here's one scenario of what happens, if I am a cracker:

1.  I register for a site several times and each time I am sent back a cookie with a 
fixed length
value.  Hmm... that suggests to me that it might be a digest.

2.  Since I already know the plaintext and now have the ciphertext, I can run my 
plaintext through
various known digest algorithms to see if I have a quick match.  If not, that suggests 
that
they're either using an algorithm that I'm not familiar with or they've added some 
extra data to
my password that makes a brute force more difficult.

3.  If I can't get the quick match, I'm forced to do a more rigorous analysis of the
ciphertext/digest or try to gain more information about the system (see if I can grab 
source code
or use social engineering to get info).  I could also try to brute force the extra 
data, if I
thinks it's being added.

Sending back a password digest then relies on two secrets:  the password and $rand 
text that's
added (I say $rand text, but it should never change.  I mean rand as in 'difficult to 
guess'). 
Since it's a one-way function, *in theory* it should be difficult to crack password 
even without
the extra text that's added ... assuming that a secure password policy is put in place 
-- but such
policies are usually a joke.

That being said, I do agree with Joel that sending back a password digest is not the 
most secure
method.  It's not a *bad* method, if implemented properly, but it was a quick and easy 
fix for the
original question.  A better method is to send back a session ID that's completely 
unrelated to
the information that needs to be secured.  That's why I suggested reading
http://www.perlmonks.org/index.pl?node_id=101247.  It relies on randomly generated 
session ID's to
track users.  It's much more secure, but it's also more difficult to implement 
properly if you're
new to Perl.

Cheers,
Curtis Poe

=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and Security

[Ryan Davis]

OK, I know this is getting a little off-topic, but I think security is a big
issue, especially with newbies like myself, and deserves some good
discussion. Also, there's probably not a perl-cgi-beginners-security list,
nor should there be.

I looked at the perlmonks article, and had some trouble making sense of it,
but here is my idea:

1) User first signs up, gives a password.  The password is passed through
MD5
to make a digest, and the digest is stored in a password database.

2) A session ID is generated and written to the cookie (instead of the
password), and to a database.  The ID is itself digest based on username,
time, and another string, $rand.

3) The script reads the session ID from the cookie, compares it to the
database, and if it is found, then the user is considered logged in

4) When the user logs out, the session ID is deleted from the DB, and any
other session IDs older than, say, 1 day are deleted from the DB as well, to
take care of people who don't log out properly.

Is making the session ID a digest just extra processing, or does it have a
point?

My application is for a student group I'm involved in, and I'm guessing
other student groups might enjoy trying to hack in and put bad data into the
database I'm interacting with, to make my group look bad.  Kinda reminds me
of West Side Story, but a lot geekier and with less singing.

Thanks for any help,
Ryan


- Original Message -
From: Curtis Poe <[EMAIL PROTECTED]>
To: CGI Beginners <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 12:42 PM
Subject: RE: Cookies and Security


> --- Joel Hughes <[EMAIL PROTECTED]> wrote:
> > Curtis,
> > are you sure that sending the digest back to the client in cookie form
is a
> > good idea?
> >
> > I mean, if I were a hacker, could I not register and then retrieve the
> > digest - you then have the plain text and the cipher text. (admittedly
you
> > would have to know that whats in your cookie is a digest rather than
another
> > form of session id but stilll...)
> >
> > I'm not sure how easy it is then discover which algorithm is used when
you
> > have the plain & cipher but, seeing as MD5, is fairly popular - that
might
> > be a good starting point for the hacker to mount an assault on
discovering
> > the function.
> >
> > joel
>
> Joel,
>
> That's a good question.  The idea here is that the best security protocols
should have their
> details openly available to anyone and still be relatively hard to crack.
The solution is
> suggested, while not the best, is still relatively secure if implemented
properly.  However, if
> you're protecting banking information or medical records, I'd opt for an
even more secure
> mechanism.
>
> Regarding your concerns, here's one scenario of what happens, if I am a
cracker:
>
> 1.  I register for a site several times and each time I am sent back a
cookie with a fixed length
> value.  Hmm... that suggests to me that it might be a digest.
>
> 2.  Since I already know the plaintext and now have the ciphertext, I can
run my plaintext through
> various known digest algorithms to see if I have a quick match.  If not,
that suggests that
> they're either using an algorithm that I'm not familiar with or they've
added some extra data to
> my password that makes a brute force more difficult.
>
> 3.  If I can't get the quick match, I'm forced to do a more rigorous
analysis of the
> ciphertext/digest or try to gain more information about the system (see if
I can grab source code
> or use social engineering to get info).  I could also try to brute force
the extra data, if I
> thinks it's being added.
>
> Sending back a password digest then relies on two secrets:  the password
and $rand text that's
> added (I say $rand text, but it should never change.  I mean rand as in
'difficult to guess').
> Since it's a one-way function, *in theory* it should be difficult to crack
password even without
> the extra text that's added ... assuming that a secure password policy is
put in place -- but such
> policies are usually a joke.
>
> That being said, I do agree with Joel that sending back a password digest
is not the most secure
> method.  It's not a *bad* method, if implemented properly, but it was a
quick and easy fix for the
> original question.  A better method is to send back a session ID that's
completely unrelated to
> the information that needs to be secured.  That's why I suggested reading
> http://www.perlmonks.org/index.pl?node_id=101247.  It relies on randomly
generated session ID's to
> track users.  It's much more secure, but it's also more difficult to
implement properly if you're
> new to Perl.
>
> 

Re: Cookies and Security

[Curtis Poe]

--- Ryan Davis <[EMAIL PROTECTED]> wrote:
> OK, I know this is getting a little off-topic, but I think security is a big
> issue, especially with newbies like myself, and deserves some good
> discussion. Also, there's probably not a perl-cgi-beginners-security list,
> nor should there be.
> 
> I looked at the perlmonks article, and had some trouble making sense of it,
> but here is my idea:
> 
> 1) User first signs up, gives a password.  The password is passed through
> MD5
> to make a digest, and the digest is stored in a password database.

Yes.
 
> 2) A session ID is generated and written to the cookie (instead of the
> password), and to a database.  The ID is itself digest based on username,
> time, and another string, $rand.

Slightly different from how I'm doing it, but this is perfectly fine.  I include some 
other stuff,
but I might want to add the username to my digest computation (NOT to the cookie).  
Thanks for the
idea!

> 3) The script reads the session ID from the cookie, compares it to the
> database, and if it is found, then the user is considered logged in

Almost.  Once the first digest is created, the user is then considered logged in.  
Later, when the
script reads the session ID from the cookie, it compares it with the digest and, if 
they match,
the user is considered to be *still* logged in.  This may be what you meant, but I 
wanted to make
sure.

> 4) When the user logs out, the session ID is deleted from the DB, and any
> other session IDs older than, say, 1 day are deleted from the DB as well, to
> take care of people who don't log out properly.

Don't depend on the user logging out.  Many of them will simply close their browser 
and not
logout.  In my code, when I check the digest, I also check a timestamp in the 
database.  If that
timestamp is greater than the "inactive" time allowed, then I log them out 
automatically.  Just
make sure that you don't depend on the cookies expiration time as you cannot control 
the whether
the user agent abides by this expiration time.

Later, when you create the next session ID and store it in the database, don't forget 
to update
the timestamp in the database.

> Is making the session ID a digest just extra processing, or does it have a
> point?

You could generate a random session ID and this would be faster than creating a 
digest.  I like
the digest method because, if done properly, it's much less likely to generate a 
duplicate session
ID.

Also, every time I read the cookie, I generate a new session ID, store it in the 
database, and
return the new ID.  That way, if someone is sniffing the connection and grabs a 
session ID, they
are less likely to hijack a session by supplying that session ID.  Further, with the 
timeout
feature, if they sniff the ID and try to use it too late, they still can't get in.

The only way to hijack the session with this method is to sniff the session ID and 
submit it as a
cookie *before* the real user has a new ID used.

One final note, despite what it says on the Perlmonks link that I supplied, the 
*entire* admin
console is now encrypted (we convinced the client that this was a good idea).  
Further, the cookie
that is sent is now a "secure" cookie and can only be sent over a secure connection.  
As a result,
even though it's tough to crack the cookie info, it's now much tougher because it's 
been
encrypted.  Here's the CGI.pm code that I use to generate the cookie:

my $cookie = $q->cookie( -name   => SESSION_COOKIE_NAME,
 -value  => $value,
 -path   => '/',
 -secure => 1 );

The SESSION_COOKIE_NAME is a constant to ensure that the cookie naming doesn't get out 
of synch. 
The $value is the digest and the "-secure => 1" instructs the user agent to only 
return the cookie
over a secure connection.

> My application is for a student group I'm involved in, and I'm guessing
> other student groups might enjoy trying to hack in and put bad data into the
> database I'm interacting with, to make my group look bad.  Kinda reminds me
> of West Side Story, but a lot geekier and with less singing.

I dunno.  Singing geeks sounds cool to me :)

If you're curious about the login table, it's something like this:

user varchar(20)
password char(22)(because the digest created is always 22 characters long)
time datetime(this is the time the last cookie was sent)
active   bit (if they get locked out or their time expires, I set this to zero)
session  char(22)(sessionID digest)
timeout  int (number of minutes they may be 'inactive')
attempts int

As for the "attempts" field, if a particular user name fails a login, I increment 
attempts by one.
 After

RE: Cookies and Security

[Fields, Aubrey]

Joel is right. A "known plaintext" attack is very effective... and sending a sample of 
you encryption to anyone is risky.

Also, just for information sake, you can recover passwords from digest form... sort 
of. Ever heard of "Crack" or "John the Ripper"?

If you enforce strong passwords then it is much more difficult, but the "known 
plaintext" attack will still succeed, eventually. Even 128 bit encryption has been 
broken this way. To make things worse, if a user can set his/her password to 
"password" I'd give your security 10 minutes before it cracks. 

I have a suggestion that might help. You could send cookie that is just a pointer to a 
file location or a key of a database on your server. One of you severs could use the 
(more or less) harmless information that you send in the cookie to look up what the 
digest password would be. 

That would prevent "the evil hacker" from breaking into your site using data that you 
are sending to him/her.
 
 Cybear

> Curtis,
> are you sure that sending the digest back to the client in cookie form is a
> good idea?
> 
> I mean, if I were a hacker, could I not register and then retrieve the
> digest - you then have the plain text and the cipher text. (admittedly you
> would have to know that whats in your cookie is a digest rather than another
> form of session id but stilll...)
> 
ps - hackers are called hackers because they play with things. Eventually, if you site 
is interesting enough, someone would try decrypting the info in the cookie.


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies stopped working

[MARCOS LABORDE]

Hi there,

Your code looks OK...but first I'd tie the -NAME  key to   => $your_true_reference
and also eliminate the comma after the $user value.

It should work that way.

Good luck.

Marcos

>>> "Kirk W. Batzer" <[EMAIL PROTECTED]> 10/30/01 10:38PM >>>
I'm attempting to port a perl CGI application
from:  "perl, 5.005_02 built for 3446-svr4.0"
to:"perl, v5.6.1 built for sun4-solaris"

The application uses "cookies" to maintain "state" information.  The
following code is successfully creating and using cookies in the perl
5.5 , but failing to create cookies in the perl 5.6 environment.

==
use CGI qw(:standard);
use MIME::Base64;
...
%mylist = &SelectFromTable(*table, *collist, *wherelist);

local(@userinfo) = ($mylist{userid},
$mylist{usertype},
$mylist{username},
$mylist{phone},
$mylist{groupname},
$mylist{email});

local($user) = encode_base64( join(":", @userinfo) );

$cookie = cookie(   -name=>'loginfo',
-value=>$user,
);
print header(-cookie=>$cookie);

===

I've noticed the CGI.pm docs show a true reference when creating and
fetching cookies.  I'm wondering if this is contributing to this
problem?  The above code seems to use an anonymous reference where the
docs example, below use a true reference "$query".

>From CGI.PM docs:
use CGI;
$query = new CGI;
$cookie=$query->cookie( -name=>'family information',
-value=>\%childrens_ages
);


I'm not the perl CGI-cookie expert.  I'm attempting to learn more by
porting this code.  Any help would be appreciated.

Kirk




-- 
To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: web and cookies

[_brian_d_foy]

In article <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] (Zaka rias) wrote:


> if some users come into my site, that script will
> catch the user ip and write it to iplog.txt file

why not simply look in the access log? it should already
have that information.
-- 
brian d foy <[EMAIL PROTECTED]> - Perl services for hire
CGI Meta FAQ - http://www.perl.org/CGI_MetaFAQ.html
Troubleshooting CGI scripts - http://www.perl.org/troubleshooting_CGI.html

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

setting and retrieving cookies

[Matthew Harrison]

Ok, now i am pretty sure what i have done is right because i copied it from 
a book, but I don;t know if it is right to set or retrieve a cookie. here 
is my script that should set a cookie, allowing visitors to customise the 
look of my site:

#!/usr/bin/perl

use CGI qw/:standard/;
$q = new CGI;
print header();

$cookie = $q->cookie(-name=>'fontsize',
  -value=>'12',
  -expires=>'20s',
  -domain=>'http://www.peanutbuttercheesecake.co.uk');

why isn't anything happening. my browser is set to ask if i want to accept 
a cookie, but it doesn't ask.
TIA

-- 
Matthew Harrison
Internet/Network Services Administrator
Peanut-Butter Cheesecake Hosting Services
Genstate
www.peanutbuttercheesecake.co.uk


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

nearly got the cookies

[Matthew Harrison]

I have manager to set a cookie containing a hash of 4 keys and 4 values. 
This is the script i have to retrieve the cookies and modify the look of 
the page using them. i have constructed it using bit frmo www.perldoc.org.
it keeps saying it cannot run because of something in the way i am 
retieving the cookies. what is wrong?

#!/usr/bin/perl

use CGI qw/:standard/;
use CGI::Cookie;

%cookies = fetch CGI::Cookie;
$font = $cookies{'font'}->value;
$size = $cookies{'size'}->value;
$color = $cookies{'cookie'}->value;
$back = $cookies{'back'}->value;

print header();

print <


hello people, hope you like your prefs.




END_OF_HTML

-- 
Matthew Harrison
Internet/Network Services Administrator
Peanut-Butter Cheesecake Hosting Services
Genstate
www.peanutbuttercheesecake.co.uk


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Accepting cookies with LWP?

[Octavian Rasnita]

Hi all,

I've tried to get a web page with the following line:

use LWP::Simple;
my $page = get($path);

The problem is that LWP gets another page telling me that I should login or
I should enable my browser to accept cookies.

What should I do to make LWP to accept cookies?
Is it possible with LWP::Simple, or I should use LWP::UserAgent?

Thank you.

Teddy Center: http://teddy.fcc.ro/
Mail: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sending and Reading cookies

[Wiggins d'Anconia]

Is the line being displayed?  In that case you are likely printing the 
cookie after the header has already been printed, which is not allowed 
(or at least not standard, though I think some browsers may accept them).

More specific information is going to be needed, and posting a larger 
portion of your script would be much more helpful.

You might also considering using a library to handle cookies for you, 
such as the CGI module, or the many free variants.  These will lessen 
the amount you have to know about HTTP and make sure you cover your bases.

http://danconia.org



Jerry Lawson wrote:
> I'm having trouble sending a cookie. The book I have says to send a
> cookie the code 'print "Set-Cookie:name=value\n";' will work. When I
> implement this code in my script, the cookie is not being set. Can
> someone tell me what I am doing wrong?
> 
> Thanks,
> 
> Jerry Lawson
> 
> 
> 
> 


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies and IP Addresses

[Robin Cragg]

Hi,

not sure about the REMOTE_ADDR, I've never had any problems with it. To get 
an IP from a URI try this:

use Socket;
$referral_address = $ENV{'HTTP_REFERER'};
$referral_address =~ m#^.*http://([^/]+)/.*$#;
$IP =  inet_ntoa inet_aton $1;


If you want the IP address in hex, just use inet_aton.


R

At 11:06 03/10/2002 +0100, Mike Craig wrote:
>Hi all,
> Can you help me with this?
>
> I want to get the servers IP address and the IP address of the 
> referrer. Is
>there a reliable way to do this? When I used 'REMOTE_ADDR' I get different
>values even when I go directly to my site and then call 'REMOTE_ADDR'. Does
>anyone know why? I want to use the IP address to ensure that some of the
>code is only called from my site or from a valid IP address. I want the IP
>address and not the URL so I can convert it into Hex.
>
>$ENV{'SERVER_NAME'};
>$ENV{'HTTP_REFERER'};
>$ENV{'REMOTE_ADDR'};
>
>
>     In the discussions on cookies does any one know why when I set a 
> cookie and
>restart some time later my cookies are lost when I do the following in
>JavaScript
>
>var cookieDate = new Date()
>cookieDate.setTime(cookieDate.getTime() + 10 * 365 * 24 * 3600 * 1000);//Add
>10 years
>
>document.cookie = escape("MyCookie=XXX" + ";expires=" +
>cookieDate.toGMTString() + ";domain=.UltraTextPro.biz");
>
>Mike
>
>
>--
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

two cookies from one domain

[aman cgiperl]

Hi
How do I set two cookies, from two different scripts, same domain?
I tried with different names for cookies as follows and I lose'em

Script1.cgi has the following code:

my $ct = &rnd_num;# random
number generator
use CGI::Cookie;
my $cook = new
CGI::Cookie(-name=>'cok.cart', -value=>$ct, -domain=>'.192.168.0.1');
print header(-cookie=>$cook);

Script2.cgi has the following code:

my $name = &get_mail_id;  # user's email
use CGI::Cookie;
my $cook = new
CGI::Cookie(-name=>'cok.email', -value=>$email, -domain=>'.192.168.0.1');
print header(-cookie=>$cook);


They probably conflict or something. Not sure.
Any ideas?

Thanks
Aman

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Cookies - might be off topic

[Octavian Rasnita]

Hi all,

I want to create a script that sets a cookie that will be returned by the
visitor's browser when they will visit more domains like:

www.mamajob.net
www.mamashop.net
www.mamabay.net

.. etc.

Is it possible?
If yes, how can I set more domains for a cookie?

Thank you.

Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cookies with CGI and IE7

[Andrew Brosnan]

Anyone having trouble setting or retrieving cookies with CGI.pm and IE7?

I'm doing:
my $cookie = $q->cookie( -name=> 'session',
 -value   => $session,
 -expires => '3h',
print $q->header( -cookie => $cookie);

I got some feedback that the cookie wasn't working in IE7.

I hate cookies.


Andrew

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Cookies v. Hiddent Fields

[Wiggins d Anconia]

> 
> What is the difference (as far as security goes) between using a
cookie and
> a hidden field? Are hidden fields cached if we are using SSL? I think
not. 
> 
>

None. Both are wide open. SSL simply encrypts the "pipe" between your
server and the client (browser). Everything passing over it, including
cookies and hidden fields, is encrypted, or not if SSL is not employed.
  I like the pipe analogy, think of everything that goes from the
browser to the server (and since both cookies and hidden fields are
client side until the client calls to the server) as traveling over a
clear pipe. So if you can see into the pipe, then you can see
everything. Then picture SSL as a wrapper around the pipe, it prevents
you seeing *everything* traveling over the pipe, so then it is up to you
to make sure the connections at either end work (aka browser supports
SSL, server does too, and they have decided to use the covered pipe
instead of the clear one).
  
> 
> If I use a GUID as a session ID in my database and store the GUID in a
> hidden field and the user sees the GUID in some GET parameters, is this of
> any consequence? 
> 

Depends on what the GUID is made of.  Did my other write up of the
authentication idiom not help? work? or the modules suggested by the
other poster?

>  
> 
> Someone recommend that I don't persist cookies. How do I not persist
> cookies?
> 

They shouldn't persist by default, it is usually a question of "how do I
make them persist", whic his covered very clearly here:

http://search.cpan.org/~lds/CGI.pm-3.05/CGI.pm#HTTP_COOKIES

http://danconia.org


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: Cookies v. Hiddent Fields

[Octavian Rasnita]

From: "Siegfried Heintze" <[EMAIL PROTECTED]>


> What is the difference (as far as security goes) between using a cookie
and
> a hidden field? Are hidden fields cached if we are using SSL? I think not.
>
>

Both have the same security.
A hidden field is simpler to be viewd by a user, but a cracker can see them
both.

>
> If I use a GUID as a session ID in my database and store the GUID in a
> hidden field and the user sees the GUID in some GET parameters, is this of
> any consequence?
>

No, no problem, but it depends how you define that hidden field.
For exemple, don't use as hidden fields autoincreasing numbers but always
use random strings.

>
>
> Someone recommend that I don't persist cookies. How do I not persist
> cookies?
>
>
>

Don't put an expiration date and they will  not be persistent.

Teddy


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: cookies as hidden files

[Sean Davis]

On 9/16/05 12:08 AM, "Denzil Kruse" <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> I read through the docs for CGI::Cookie and learned
> how to set a cookie.  I do it with line:
> 
> my $cookie = new CGI::Cookie(-name=>'name',
>-value=>"$name",
>-expires=>'+6M');
> 
> But, I've found out that when IE creates the cookie,
> it creates it as a hidden file, so when I come around
> and fetch it, it can't find the cookie and hangs.
> 
> But, I saw some cookies that weren't hidden.  The list
> just got bigger once I told windows to how hidden
> files.  
> 
> So, my question is, how can I create the cookie in
> such a way that it isn't hidden?  I couldn't find it
> in the docs I looked through.

Cookies are stored on the client side while they are generated and read from
the server side.  Whether or not the cookie is in a hidden file makes no
difference as long as the browser knows where the cookie is, which it
presumably does.  

Sean


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: cookies as hidden files

[Sara]

1. Are we setting up the proper headers?

use CGI;
my $q = new CGI;

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

2. I am unable to see the

-domain => 'foo.com';

3. On which machine, you are testing? Your Windows (localhost) or a real web 
server?. I have always experienced problems locating cookies for my 
localhost (Windows XP, Apache). But when I ran the scripts on my *nix Web 
Server, those worked fine.


4. When dealing with cookies and calling the scripts within your browser, 
don't hit your refresh button while testing the script, always call the 
script in a new window for fresh headers.


I have never experienced HIDDEN cookies, new phenomenon for me atleast.

HTH,
Sara.

- Original Message - 
From: "Denzil Kruse" <[EMAIL PROTECTED]>

To: 
Sent: Friday, September 16, 2005 9:08 AM
Subject: cookies as hidden files



Hi all,

I read through the docs for CGI::Cookie and learned
how to set a cookie.  I do it with line:

my $cookie = new CGI::Cookie(-name=>'name',
-value=>"$name",
-expires=>'+6M');

But, I've found out that when IE creates the cookie,
it creates it as a hidden file, so when I come around
and fetch it, it can't find the cookie and hangs.

But, I saw some cookies that weren't hidden.  The list
just got bigger once I told windows to how hidden
files.

So, my question is, how can I create the cookie in
such a way that it isn't hidden?  I couldn't find it
in the docs I looked through.

thanks,
Denzil



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>





--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: cookies as hidden files

[Denzil Kruse]

Well, this is what I witnessed.  I'm using a windows
computer at home.  It is configured to display hidden
files.  I have a red hat linux server off who knows
where that hosts my site.

I set up a perl script to set and fetch cookies, and
it does so correctly on my computer.  But, I went over
to a friend's windows computer, and when it tried to
bring up the site, the browser(IE) hung.  Part of the
web site is a flash presentation with music, but the
flash was hanging as well, and there was no music.

So I start looking for the cookies on the local
machine.  I couldn't find it, so did a search on the
entire machine.  Still couldn't find it, which freaked
me out be because I knew it was there.

So, I went into the folder options or whatever it is
called and told the computer to display hidden files. 
The moment I did that, the cookies appeared in windows
explorer in the cookies directory, and the music from
the flash presentation started playing.

So I concluded that if windows explorer couldn't see
the cookie, then IE couldn't either.  I suppose I
could do a few more experiments, but it sure seems
like that cookie was hidden and couldn't be found.

Before I displayed the hidden files, there were
cookies in the cookies directory.  So some cookies
aren't considered hidden files and others are.  I'm
trying to figure out how to get my cookies to not be
hidden/system files so they appear.

Denzil

--- Sean Davis <[EMAIL PROTECTED]> wrote:

> Cookies are stored on the client side while they are
> generated and read from
> the server side.  Whether or not the cookie is in a
> hidden file makes no
> difference as long as the browser knows where the
> cookie is, which it
> presumably does.  
> 
> Sean
> 

> 




__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: cookies as hidden files

[Denzil Kruse]

--- Sara <[EMAIL PROTECTED]> wrote:

> 1. Are we setting up the proper headers?
> 
> use CGI;
> my $q = new CGI;
> 
> print $q->header(-cookie=>$cookie);
 
I think so.  I did it this way:

my $cookie = new CGI::Cookie(-name=>'name',
 -value=>"$name",
 -expires=>'+6M');

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

> 2. I am unable to see the
> 
> -domain => 'foo.com';
> 

I left that out.  The docs say "If no domain is
specified, then the browser will only return the
cookie to servers on the host the cookie originated
from."  Which is what I want I think?

> 3. On which machine, you are testing? Your Windows
> (localhost) or a real web 
> server?. I have always experienced problems locating
> cookies for my 
> localhost (Windows XP, Apache). But when I ran the
> scripts on my *nix Web 
> Server, those worked fine.

yes, I'm using a linux red hat server off on the
internet somewhere.

> 
> 4. When dealing with cookies and calling the scripts
> within your browser, 
> don't hit your refresh button while testing the
> script, always call the 
> script in a new window for fresh headers.
 
Okay.

> I have never experienced HIDDEN cookies, new
> phenomenon for me atleast.

I'll go through and double check.  It could have been
some weird coincidence, but I don't think so.
> 
> HTH,
> Sara.

Thanks for your help,
Denzil



__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: cookies as hidden files

[Bob Showalter]

Denzil Kruse wrote:

Well, this is what I witnessed.  I'm using a windows
computer at home.  It is configured to display hidden
files.  I have a red hat linux server off who knows
where that hosts my site.

I set up a perl script to set and fetch cookies, and
it does so correctly on my computer.  But, I went over
to a friend's windows computer, and when it tried to
bring up the site, the browser(IE) hung.  Part of the
web site is a flash presentation with music, but the
flash was hanging as well, and there was no music.


Whatever problem this is, it isn't a Perl problem. Your CGI script neither 
reads nor writes files on the client PC; the browser handles all that. 
Sounds like your friend's browser is broken? Or perhaps he has cookies 
disabled, in which case any cookies sent by your script are simply discarded 
and you won't see them come back. 



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: cookies as hidden files

[Denzil Kruse]

I've spent the morning trying to reproduce it on my
machine and my brothers, and can't seem to do it.  It
must have been some kind of coincidence or fluke.

Thanks for your help everyone.  I'll let you know if I
ever figure it out.

Denzil

--- Bob Showalter <[EMAIL PROTECTED]>
wrote:

> Whatever problem this is, it isn't a Perl problem.
> Your CGI script neither 
> reads nor writes files on the client PC; the browser
> handles all that. 
> Sounds like your friend's browser is broken? Or
> perhaps he has cookies 
> disabled, in which case any cookies sent by your
> script are simply discarded 
> and you won't see them come back. 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>