[thelist] JavaScript Pseudo-Security

Hershel Robinson hershelr at netvision.net.il
Sun May 26 08:52:01 CDT 2002


I am in the process of rebuilding the IU of a large, commercial,
limited-access website from a litany of ugly DreamWoven HTML pages into a
slick webapp.  If anyone is interesting to discuss my system and my approach
to it, I would happy to talk about it off-line.  I can always use a bit of
advice. :)

The one question I do want to ask the list, however, concerns the
cookie/relogon functionality.

At present, the system uses the CGI and short-lived cookies to verify users'
identities.  On cookie expiration, the user receives a relogon page and then
receives his requested HTML page.  My boss would like for the client-side JS
code to initially deal with relogons.  He would like a JS pop-up window
(probably virtual) to appear on top of the webapp and request a username and
login after X seconds of inactivity.  The system only supports IE6.0 (and
there are no plans to include other browsers at present) so the JS is a
little easier to deal with.

I thought of two approaches to this problem:

1 Have the JS examine the cookie and then when the user requests a new page,
or perhaps on a keystroke/mouse event, check the cookie to see if it's still
valid.  This idea, however, has *several* drawbacks.

2 Have the JS fire a small function on each keystroke/mouse event (perhaps
excluding mousemove events) and set a variable with the current timestamp.
With the next keystroke/mouse event, I can compare the current timestamp to
that of the last event and thus determine how much time the user has been
inactive.  If need be, I can then freeze input to the page and pop up a
window requesting a password.

I believe I can catch all events except Refresh and Back.  Refresh is not
such a concern because in such a case, the user is actually requesting a new
web page and so to present him with a stand-alone HTML page (i.e. not an
inherent part of the webapp) would not be incongruous.  The Back event,
however, concerns me.  At present, the page he will be Backing up to will
most probably have expired already and so he will see that cute little
default your page has expired message.  What he will do then I suppose would
be either to forward and proceed normally or to Refresh.

This Back issue is not a large concern because the webapp has its own back
feature (a button) and I think most users are used to using it.  I would
like to deal with it in an as-elegant manner as possible, however, because
I'm sure it will come up.

Any thoughts, ideas or suggestions as to all I have written are appreciated.
I don't program in a vacuum exactly, but my programming team does consist of
basically... me.

Thanks,
Hershel




More information about the thelist mailing list