fp and web server session management example

Fairlight fairlite at fairlite.com
Sat Oct 28 02:24:29 PDT 2006


You'll never BELIEVE what Scott Nelson said here...:
> Has anyone created a session management system using filepro for fp web 
> services?

Now that I've had a bit of time to move something between servers and
ensure that it's actually usable there...

http://www.fairlite.com/fc/products/flfss/

That's the main index for the file sharing room we used to use with John
Esak's fP Room.  It's no longer in active production, as it wasn't being
used much anymore and I renegotiated some server use issues--which left me
without a web server that had fP on which I could run it.  Anyone that used
it, including John, can attest that it was a functional system.

At any rate, all the code and implementation is still available via the
magic of packrat archives.  :)  Today's your lucky day...

In particular, pay attention to the paragraph about sessions at the end of
the intro section, and the following links:

prc.make_sessionid
prc.insert_session
prc.update_session
prc.verify_session
prc.clean_sessions
prc.make_cookie  (if you want to use cookies -as well as- sessions)
prc.remove_cookie  (if you want to use cookies -as well as- sessions)

Also look at how insert_session and verify_session are being used.  Take a
look at:

prc.login (lines 25-50)
prc.list_files (line 20, lines 24-39)

What's being done in list_files is pretty much byte-for-byte identical in
every other main table that's used after login has succeeded, so you can
look at any of them and see the same thing.  Note that on line 20 of
list_files, I'm grabbing the session ID from a field named "session" that I
pass along every single handshake on down the daisy chain of transactions.
I happen to be doing it there in the context of OneGate, which is why it's
in a lookup.  But it's being passed as a field every step of the way.

Note also that session ID's were created by taking the guaranteed-unique
portion of the incoming data's filename as generated by OneGate.  I later
added an environment variable ONEGATE_UNIQUE that would give you access to
this without having to actually use a make_sessionid.  However, without
OneGate you'd need to actually go through the process of making a unique
string identifier for each session inside filePro rather than stripping
down or using external data.  "Date-Time-REMOTE_ADDR" (with the appropriate
formatting, substitution, and concatenation) should be a sufficiently
unique string for this purpose.  QED.

Note that I was using clean_sessions nightly from cron.

All maps are available there as well.  I didn't track much.  Just enough
for what I wanted--namely, unhijackable sessions that I could expire
at-will and regenerate with new session IDs if cookies were in use
(optional).  By unhijackable, I mean even -if- someone could guess a valid
session string, it would be useless to them unless they used it from the
IP# with which it was originally associated.  That's how I intentionally
designed it.  As for cookie vs session conflicts, it only made sense to me
that you don't log someone out of a system if they've selected "Remember
Me" cookies; in this event, I generate a new session, assign it to the
same IP#, and all of them are there for statistical analysis and audit
trails--at least until clean_sessions gets a hold of them, and that was
tuneable if you tweak the calculation in the processing.  There's enough
info in the sessionids map to be able to clean at far finer granularity
than I was doing.

If you need more help than the raw maps, source, and the pointers to the
line ranges, I'm more than happy to help--but it's going to be offlist, and
it's not going to be free.  Please contact me privately if you still need
assistance with this example.

Hope this helps.  It's pretty generic, given the replacement of the guts of
make_sessionid, which is dead trivial.  Hopefully this is of some use to
you.

Bests,

mark->


More information about the Filepro-list mailing list