I have also been doing problem solving related to session handling and I
will briefly share my ideas for a solution. What I am about to say is
just the logic or protocol behind my solution without getting into
implementation details. I don't know if it'll help you, but here goes:
Essentially I had a server-side data store that tracked 4 pieces of
information on a client session for authentication purposes:
1. session code or login name (primary key)
2. the "realm"/cookie that the client got on the last log in
3. the date and time of their last log in or request
4. the IP address (or something) of the client machine when last logged in
The above information is checked each time the client makes a request. If
any is not acceptible then they are prompted for their user id and
password again. "acceptible" means that the realm and IP are the same as
before, and that less than a certain amount of time passed since they were
prompted for a password. If users log out then the "realm" is reset to
nil so that they would have to be prompted on a log-in later.
HTTP authentication can be used to gather the login name and password, or
an html form could be used (greater compatability). It doesn't
really matter.
The back-end data store also remembered the cumulative effect of whatever
users did during the session, so it doesn't all need to be passed back and
forth by the browser. So if the web browser crashes or they move to
another computer or their session times out, all they have to do is
answer the new prompt for a username/password and they can continue right
where they left off. This also means that their short-term workflow is
remembered, so they have the same screen they left with. The actual
commitment of their changes is only done at certain times, such as when
they request to save changes. Meanwhile, the actual back-end data isn't
left in a volatile state.
I think that my solution has advantages of convenience, security, data
integrity, compatability and so forth. Also, web browsers have very
little that they need to remember. The catch is that users need to have
login ids and passwords, and that their activity is tracked by the server
(at least short term). But my solution was designed for users who were
registered and approved to edit the database, not anonymous individuals.
Although, this methodology could still be adapted for anonymous uses...
FYI: My requirements were to facilitate a web-accessible resource that
could be edited by multiple registered people at once, and as such, each person
would have their own login name and password. Fairly standard so far,
right? But in addition to that, it needed to let them do their work at a
public station or office where the same user could be sitting at several
different computers in one day, and several people could use the same
computer. Additionally, an editing task could be either simple or quite
involved, meaning that the user may have to abandon their session and
continue where they left off later. I needed precautions against the
browser crashing or it being left open after the user leaves for others to
see. Finally, the edited information would be hierarchical, often
requiring multiple screens, as well as going up a path and then returning,
with what they did up the path being remembered. The same user may even
want to edit several unrelated pieces of information at once, doing first
one, then stopping and doing something else, and then returning to what
they were doing before.
Now, I don't know if any of this has helped you or not, but it certainly
has helped me.
Good days,
// Darren Duncan
