#1 Context Management Problems

[Jim McNeill]

Hi - sorry if I'm posting this in the wrong place, but
I'm sort of confused about the status of Steve
Southwell's Context Management System these days (and
I've lost his email address again). I have downloaded
the CMS version from the FreeFrameWork site, which as
far as I am aware does not need FreeFrameWork
installed before I can use it. Also I have looked at
the FreeFrameWork installation instructions, and to be
quite frank they're way over my head - so I'm trying
to use CMS on it's own.

To complicate matters further I'm set on serving up
XML, and have made a one line change to ffwebstate.i (
output-content-type ("text/xml":U).) so that all my
content is XML (with an xml-stylesheet processing
instruction).

My problem is that I have managed to keep a session
going while following links between pages, but I find
that when I use the prev page button in my browser
(IE5) I get a new websession record created. If I
can't rely on the session continuing with this action,
then obviously I'm going to lose a lot of the benefits
of the CMS.

However I notice that the newly created session has
the same websurfer ID, which makes me wonder whether
I'm using CMS in the right way. Looking through the
functions in the API (and reading between the lines),
perhaps I should be creating permanent webSurfer
records and picking them up when a user returns to the
site?

The surfer functions are only documented in the API,
and I would be very grateful if anyone could put
together a short idiot's guide with worked examples.
Then this idiot might have a chance of writing secure
web pages!

Regards
Jim McNeill
Systems Administrator
John Holdsworth & Co. Ltd.

PS: just in case I've inadvertently slandered anyone
in the above, the views expressed above are strictly
my own and should not be taken to represent the views
of my employers.

[Steve Southwell]

Logged In: YES
user_id=52644

This place is fine for support requests. The ffw@peg.com
address works well too, since more people read that on a
daily basis.

Steve Southwell's email address (ses at bravepointdallas dot
com) has been added to the Readme page for the Context
Management System:
http://www.freeframework.org/downloads/new/webstate/readme.shtml

New sessions only get created in the following situations:

1. The system does not receive any sort of sessionID
through a hidden field, query_string, or cookie.

2. The system receives "statereset=yes" on the
query_string. (Useful for testing)

3. The session is timed out - meaning that it hasn't
received activity in X seconds, where X is determined by the
value of the setting record: */All/General/SessionTimeoutPeriod

4. The system determines that the user's IP address has
changed AND the incoming HTTP_Referrer is not on the
approved list, as determined by the setting record:
*/All/General/ValidSessionReferrers

Common issues that have been noted with this and other
session management schemes:

1. If you navigate from a non-sessioned area, such as a
static webpage, to a sessioned area, it creates a new
session if necessary by the above criteria. If you then use
the "Back" button or any other means to navigate back into
the static portion of the site, and you subsequently
navigate back to the sessioned area of the site, you
automatically lose two of the session tracking mechanisms
for that first hit: query_string and form field. Therefore,
you must have cookies enabled for this scenario to restore
the session. PLEASE NOTE: THIS IS A COMMON ISSUE WITH ALL
SESSION MGMT SCHEMES, AND IS A LIMITATION OF THE WEB.
(Unless you wanna pay big bucks for x.509 certificates for
all your users)

2. If the value of the */All/General/SessionTimeoutPeriod
setting is too low, then sessions will timeout very quickly,
and thus will restart.

3. If the value of the */All/General/SessionArchiveDays
setting is too low, then sessions may be being deleted too
soon. Default setting should be 30 days except on the
busiest systems.

4. When going from http to https in the same session, it is
common for the user's reported IP address to legitimately
change, due to the behavior of various proxy and caching
servers. If the user's browser doesn't report HTTP_REFERER
information as a backup, then the session manager will
disallow access to the session for security reasons. (Note
that this policy is under review, and should be discussed)

WebSurfer Functionality
--------------------------
This featureset was designed to allow B2C websites to
anonymously profile visitors and store persistent data about
them rather than set cookies. It can also be used in B2B or
other login-type apps as a means to tie the web profile to a
user profile in the system without modifying the user record
schema.

There are two types of info that can be stored in the
WebSurfer profile: Public and Private.

Public data isn't really "public", it's just OK to use it
and assume it's correct without an explicit login. For
instance, if a user tells you that they prefer product
category X instead of Y, then you can display category X
when they visit your site. Even if it's not them, and just
someone using their computer, no harm done.

Private data can also be safely stored in the websurfer
profile, by using the setPrivateSurferAttribute() function.
This would be how you might store favorite credit cards,
etc. If you try to getSurferAttribute() on a
surferAttribute that is private, and the
webSession.surferVerified field is not true, then it will
return "". Thus, in login logic, you should always run the
verifySurfer() function.

Hope this info helps.