I guess what got me thinking about this stuff was this article which talks about
implementing
java servlet state machines: http://www.ddj.com/articles/2001/0105/0105i/0105i.htm
posted on
slashdot.
I don't pretend to understand a lot of it, but it did get me thinking about different
ways to
maintain user states throughout the site; I'm thinking of taking a look at
POE::Session.
BTW, we're already storing a session id in a database table
Gyepi SAM wrote:
> On Thu, May 10, 2001 at 11:00:39PM -0500, Joel Gwynn wrote:
> > Can anyone point me to some simple resources on
> > understanding/implementing state machines in Perl/SQL?
> >
> > I'm working on an ecommerce site and getting sick of all the standard
> > kludgy redundant code for maintaining state, session ID's etc. I keep
> > hearing that there are these things called "state machines" which will
> > auto-magically track all these variables.
> >
> > I need a fairly elementary primer with LOTS of examples.
>
> As others have mentioned, you don't need a state machine in the classic CS
> sense, but you may benefit from a mechanism to maintain sessions and their
> associated state. This is more of an application framework than a state
> machine, though it has some features of a state machine.
> I gave a talk on this some time ago at one of the technical meetings.
> What I implemented is similar to CGI::Session, which
> you'll find on CPAN, but with some additional features and some differences.
>
> I have seen some of these issues mentioned in various places, but not all at
> the same time. One of these days, I'll sit down and fill that void. In the
> mean time, here are some thoughts you might find useful.
>
> The basic idea is that you assign sessions to every new http connection and
> maintain any state information you need on the server side which propagating
> the session id through every page the client visits. I use a
> database table to store the session data. If you only have a single machine, you
>have more
> options about where and how to store the data. If you have multiple, load balanced
> servers, you pretty much have to keep the data in a shared database since a
> client could connect to any one of your web servers. The three biggest
> issues that came up when designing this were security, persistence, and storage
> format.
>
> Security:
> You want session id's to be breakable only with great difficulty. My
> session-id's consist of an md5 hash of a secret string and the environment
> (as a long string),the length of the environment string, and the current time;
> a random string (mod_unique is great for this), and the value of the primary key of
>the
> session (from the database). The first two are of known length, so the last
> one could be (and in fact is) of variable length. When the client sends a session id,
> it is checked against the table to be sure all these values still match up.
> Since the security of the user session depends on this ID, it must be secure.
> An attacker may be able to guess some of the values, but would have a hard time
>guessing
> all of them. This is obviously predicated on the security of the rest of the
> system including the non-web related parts. Mismatches are obviously logged.
>
> A typical session id could be:
>
> /S=708c29ade99f1b6a43f098b10c7b05f3Ov0xeozvpSQAAGVIPl4101987/
>
> Which embedded in the URL, but stripped out and placed in the environment
> with mod_rewrite before the script is called. The session id is ugly but
> useful. You could check to see if the client has cookies turned on and
> transparently put the ID in a cookie instead. CGI::Session's ids are much
> simpler and also less secure. Yes, there is more of a performance hit with
> string manipulations and the database lookups on every hit. That is part of
> the cost of security.
>
> Persistence:
> Once you have a session, you have to make sure that all links to other
> pages on your site have the session id. This essentially means you have to
> either generate them in your scripts or use templates. I use templates since
> I work with other people who are more responsible for UI issues.
>
> Storage:
> To make the interface as simple as possible for scripts, the Session
> module stores and returns scalars. Obviously this is not much of a
> limitation: I am just forcing scripts to use references when they need to
> store arrays and hashes. The database, OTOH, does not understand
> scalars. So I use the Storable module to convert the scalars into binary
> strings and MIME::Base64 to encode them for storage in the table. The
> reverse combination restores them back to scalars. CGI::Session does this too.
>
> With this, you can do cool stuff like trapping for user access to a page
> that requires them to log in and redirecting the browser to the login page,
> which, after a successful login, redirects back to the original page.
>
> This is probably more than you wanted, but it is, occasionally, worth
> talking about.
>
> -Gyepi
>
> --
> Every great mistake has a halfway moment, a split second when it can
> recalled and perhaps remedied. --Pearl S. Buck
--
========[Joel-Gwynn]-[[EMAIL PROTECTED]]=======
A train station is where a train stops.
A bus station is where a bus stops.
So now you know why they call this a workstation.
