This may seem like a simple task for those of us whom have some hands on experience
with Perl but, when I was starting out I couldn't ever get the cookie bit going. There
are lots of tutorials this is true. None however give simple step by step instruction
on creating, retrieving and deleting the things. How many of you out there have
successfully used cookies?
-----Original Message-----
From: "Curtis Poe"<[EMAIL PROTECTED]>
To: "CGI Beginners"<[EMAIL PROTECTED]>
Date: Tue Jun 26 09:33:53 PDT 2001
Subject: Re: Mainting State On IIS 4 Without Cookies/Hidden Fields
>--- David Simcik <[EMAIL PROTECTED]> wrote:
>> Hi,
>> I'm looking for a way to maintain session-like state in my perl scripts
>> running on IIS. While I'm certain I've seen modules for this under Apache,
>> are there any equivalents under IIS? I certainly willing to look at
>> workarounds as well. :-)
>>
>> Thanks.
>> DTS
>
>Since HTTP is a stateless protocol, you're asking a question that has, unfortunately,
>plagued
>developers for years. If you're trying to maintain state in httpd sessions, you have
>a few
>options.
>
>Query strings and extra path information.
>
>I don't care for this method, as one is forced to try to reliably parse all links in
>documents.
>
>Cookies.
>
>This is the most reliable. It's easy to use and doesn't matter if the user leaves
>your site and
>returns later. However, if your Web site is dedicated to the premise that "BATF
>employees are
>bunch of jack-booted thugs", many of your users are probably concerned about privacy
>and have
>cookies disabled.
>
>Hidden fields.
>
>I like this method, but it only works across a series of form submissions. If the
>user leaves your
>site and returns later, state information is probably lost. One can use this with
>regular Web
>pages if Javascript is enabled and all hyperlinks are turned into form submissions,
>but this
>requires Javscript to be enabled.
>
>Regardless of the method used, you should probably be employing some form of
>generating a digest
>or random key for the session id. I prefer the idea of generating a digest with MD5
>or SHA1, since
>many people who try to generate a random key will do so on their own and not generate
>a key random
>enough. Unless you're a cryptography wiz (and I'm not), trying to "roll your own" is
>bad if you
>are really concerned about security.
>
>Ugh! I just read your subject. You want to do this *without* cookies or hidden
>fields. You'll
>have to go with the first option, which is ugly. The problem you're facing is that
>there is no
>reliable way to ensure that you're talking to the same person at any given time.
>(IP's can
>frequently change, even for the same person on the same session).
>
>If you're interesting in using user information to generate a digest, the following
>algorithm is
>listed in 'CGI Programming with Perl', second edition, by O'Reilly (how the heck do
>you properly
>attribute a book, anyway? I can never remember):
>
>use Digest::MD5;
>
>my $md5 = new Digest::MD5;
>my $remote = $ENV{REMOTE_ADDR} . $ENV{REMOTE_PORT};
>my $id = $md5->md5_base64( time, $$, $remote );
>$id =~ tr|+/=|-_.|; # Make non-word characters URL-friendly
>
>Further, here's a quote from the book regarding this method:
>
>This does a good job of generating a unique key for each request. However, it is not
>intended to
>create keys that cannot be cracked. If you are generating sessions identifiers that
>provide access
>to sensitive data, then you should use a more sensitive method to generate an
>identifier.
>
>Cheers,
>Curtis 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
>http://personal.mail.yahoo.com/
/~_. _ | _ _ _ _
\_/|(_||| | |(_)| |
_|
___________________________________________________
GO.com Mail
Get Your Free, Private E-mail at http://mail.go.com
