Home > Archive > PERL Miscellaneous > May 2005 > Setting cookie values - repeat necessary?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Setting cookie values - repeat necessary?
|
|
|
| Hey everyone,
I have built a small script that I will be using in a CGI environment. The
script does work fine, but as I have learned from all you nice people
recently, that some of my ways are "newbie"ish and can sometimes be
inefficient. I always use strict now, that at least may please some of you
:). Anyways, here is the script:
#!/usr/bin/perl
use lib '/cgi-bin/lib/';
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);
use CGI::Cookie;
use My::Crypt;
use strict;
#use warnings; // blocked out, un-useful in CGI environment
my $crypt = My::Crypt->new( debug => 0 );
my $accountID = "username";
my $passwordID = "password";
my $startpage = "vcm_main.pl";
$accountID = $crypt->encrypt($accountID, 'MM);
$passwordID = $crypt->encrypt($passwordID, 'MM');
my $cookie1 = new CGI::Cookie(-name=>'accountID',
-value=>$accountID,
-expires=>'+1h',
-path=>'/cgi-bin/program',
-secure=>0);
my $cookie2 = new CGI::Cookie(-name=>'passwordID',
-value=>$passwordID,
-expires=>'+1h',
-path=>'/cgi-bin/program,
-secure=>0);
print redirect (-cookie => [$cookie1,$cookie2], -uri => $startpage);
exit;
So the script first encrypts a username and a password. Then in $cookie 1&2
the values are set, then sent to the browser header and redirected to
another module called vmc_main.pl where the cookie values are fetched and
used. My question is ... In the first cookie definition, I set the path,
expiry and secure mode. I then do the same for the second cookie. When all
is set and done, both cookie values are ultimately stored within a single
cookie (file) on my computer. So do I need to repeat the path, expiry and
secure mode in the second cookie definition? Or will it inherit the values
from the first. I would also appriciate and reccomendations on where my
script is using outdated code or is inefficient. TIA
Robert
| |
| Brian McCauley 2005-05-30, 3:57 pm |
|
Randy wrote:
> Hey everyone,
>
> I have built a small script that I will be using in a CGI environment. The
> script does work fine, but as I have learned from all you nice people
> recently, that some of my ways are "newbie"ish and can sometimes be
> inefficient. I always use strict now, that at least may please some of you
> :). Anyways, here is the script:
>
> #!/usr/bin/perl
>
> use lib '/cgi-bin/lib/';
>
> use CGI qw(:standard);
> use CGI::Carp qw(fatalsToBrowser);
> use CGI::Cookie;
> use My::Crypt;
>
> use strict;
You may want to consider moving this up for maximum gain. Where it is
now it won't help spot mistakes in the preceeding use() statements.
> #use warnings; // blocked out, un-useful in CGI environment
Warnings are useful in a CGI environment. You should (anyhow)
periodically scan your webserver's error log. When you do so you'll see
the warnings.
If you prefer you can do:
use warnings FATAL => 'all';
This promotes all warnings to errors.
> my $crypt = My::Crypt->new( debug => 0 );
>
> my $accountID = "username";
> my $passwordID = "password";
>
> my $startpage = "vcm_main.pl";
>
> $accountID = $crypt->encrypt($accountID, 'MM);
I would recommend not encrypting the accountID cookie - it only serves
to irritate your users.
> print redirect (-cookie => [$cookie1,$cookie2], -uri => $startpage);
ISTR that setting cookies in a redirect doesn't work on some browsers.
> So the script first encrypts a username and a password. Then in $cookie 1&2
> the values are set, then sent to the browser header and redirected to
> another module called vmc_main.pl where the cookie values are fetched and
> used. My question is ... In the first cookie definition, I set the path,
> expiry and secure mode. I then do the same for the second cookie. When all
> is set and done, both cookie values are ultimately stored within a single
> cookie (file) on my computer. So do I need to repeat the path, expiry and
> secure mode in the second cookie definition?
Yes, these things can legitimately be set per-cookie. You can, of
course, put this stuff in a variable then use that variable in the two
cookie contructors.
| |
| Fabian Pilkowski 2005-05-30, 3:57 pm |
| * Randy schrieb:
>
> I have built a small script that I will be using in a CGI environment. The
> script does work fine, but as I have learned from all you nice people
> recently, that some of my ways are "newbie"ish and can sometimes be
> inefficient. I always use strict now, that at least may please some of you
> :). Anyways, here is the script:
> my $crypt = My::Crypt->new( debug => 0 );
>
> my $accountID = "username";
> my $passwordID = "password";
>
> $accountID = $crypt->encrypt($accountID, 'MM);
^^
Please use copy&paste to avoid errors like this.
> $passwordID = $crypt->encrypt($passwordID, 'MM');
>
> my $cookie1 = new CGI::Cookie(-name=>'accountID',
> -value=>$accountID,
> -expires=>'+1h',
> -path=>'/cgi-bin/program',
> -secure=>0);
>
> my $cookie2 = new CGI::Cookie(-name=>'passwordID',
> -value=>$passwordID,
> -expires=>'+1h',
> -path=>'/cgi-bin/program,
^^
Hm, it seems that your clipboard is munging some quotes. It must be
hungry. You don't feed it regularly, do you?
> -secure=>0);
>
> print redirect (-cookie => [$cookie1,$cookie2], -uri => $startpage);
>
> exit;
>
> So the script first encrypts a username and a password. Then in $cookie 1&2
> the values are set, then sent to the browser header and redirected to
> another module called vmc_main.pl where the cookie values are fetched and
> used. My question is ... In the first cookie definition, I set the path,
> expiry and secure mode. I then do the same for the second cookie. When all
> is set and done, both cookie values are ultimately stored within a single
> cookie (file) on my computer.
Sure, my browser (Mozilla Firefox) saves *all* cookies in one file,
regardless from what website they come from. You can set all these
values independently of each other, e.g. expiring the password value
after 10 minutes in order that the user has to confirm his passwort each
10 minutes, instead of confirming name and pass once an hour. (Sure, you
have to stick some code around it for doing such tasks.)
> So do I need to repeat the path, expiry and
> secure mode in the second cookie definition?
Yes, each cookie has absolutely nothing to do with other cookies,
regardless where they are created or stored.
> Or will it inherit the values
> from the first.
No. But you could alternatively use one multi-valued cookie. This means
to put an array as value:
my $crypt = My::Crypt->new( debug => 0 );
my $accountID = "username";
my $passwordID = "password";
my $cookie = new CGI::Cookie(
-name => 'account',
-value => [
$crypt->encrypt( $accountID, 'MM' ),
$crypt->encrypt( $passwordID, 'MM' )
],
-expires => '+1h',
-path => '/cgi-bin/program',
-secure => 0
);
print redirect( -cookie => $cookie, -uri => $startpage );
This way you haven't to specify all this attributes twice. Of course,
you have to adjust the code for fetching the cookie then. Please read
about this in the docs (hint: "value() is context sensitive").
regards,
fabian
| |
|
| "Brian McCauley" <nobull@mail.com> wrote in message
news:d7fakd$sa6$1@slavica.ukpost.com...
>
> ISTR that setting cookies in a redirect doesn't work on some browsers.
Oh I didn't know that. Might you have any suggestions on how I can safely
set a cookie and still get the page to redirect to the next module so the
cookies can be read?
Robert
| |
| Tad McClellan 2005-05-30, 3:57 pm |
| Randy <rbutcher.nospam@hotmail.com> wrote:
> #use warnings; // blocked out, un-useful in CGI environment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What is it that led you to that conclusion?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
| |
| Robert 2005-05-31, 3:59 am |
| "Tad McClellan" <tadmc@augustmail.com> wrote in message
news:slrnd9mfb4.jap.tadmc@magna.augustmail.com...
> Randy <rbutcher.nospam@hotmail.com> wrote:
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> What is it that led you to that conclusion?
Like I said, this is not a locally run Perl script, I is run on a commercial
web server in CGI invironemnt. Even if use warnings did generate an error or
warning in the log, I have no access to that information. I therefor opted
to not use it.
R
| |
| Sherm Pendley 2005-05-31, 3:59 am |
| Robert wrote:
> Like I said, this is not a locally run Perl script, I is run on a commercial
> web server in CGI invironemnt. Even if use warnings did generate an error or
> warning in the log, I have no access to that information. I therefor opted
> to not use it.
Even so - this is a script you're obviously still working on. Even if
you comment out "use warnings;" in the finished script that you upload
to the production server, you should still leave it enabled while the
script is in development.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
| |
| Robert 2005-05-31, 3:59 am |
| "Sherm Pendley" <spamtrap@dot-app.org> wrote in message
news:J8SdnUR5AY_oKQbfRVn-hA@adelphia.com...
> Robert wrote:
>
commercial[color=darkred]
error or[color=darkred]
opted[color=darkred]
>
> Even so - this is a script you're obviously still working on. Even if
> you comment out "use warnings;" in the finished script that you upload
> to the production server, you should still leave it enabled while the
> script is in development.
Good point, might assist in debugging during development.
R
| |
| Tad McClellan 2005-05-31, 3:59 am |
| Robert <rbutcher.nospam@hotmail.com> wrote:
> "Tad McClellan" <tadmc@augustmail.com> wrote in message
> news:slrnd9mfb4.jap.tadmc@magna.augustmail.com...
[color=darkred]
> warning in the log, I have no access to that information.
Oh, I see. Then it should have been
blocked out, un-useful in a crippled CGI environment
:-)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
| |
| Damian James 2005-05-31, 3:59 am |
| On Mon, 30 May 2005 21:13:27 -0500, Tad McClellan said:
> Robert <rbutcher.nospam@hotmail.com> wrote:
> Oh, I see. Then it should have been
> blocked out, un-useful in a crippled CGI environment
>:-)
My favorite oroborusism:
open STDERR, ">>somefile" or die "Can't redirect stderr: $!\n";
;)
--damian
| |
| Alan J. Flavell 2005-05-31, 9:09 am |
| On Mon, 30 May 2005, Tad McClellan revealed that:
> Robert <rbutcher.nospam@hotmail.com> wrote:
>
>
> Oh, I see. Then it should have been
>
> blocked out, un-useful in a crippled CGI environment
One could advise the questioner to develop their scripts in their own
environment first, where a proper range of development facilities can
be available. If they use a Windows OS, then Indigoperl seems to be
the easiest starting point, as it includes both Perl and apache in one
handy installation package. (Personally I'd recommend linux as a
better choice, but I do run Perl and apache under windows on occasion,
and for most purposes it seems close enough to the real thing to be
worth the effort).
Naturally the local installation should be configured to only be
accessible from local clients, not from the whole internet (details
of that part of the story are off-topic for here, of course).
|
|
|
|
|