James, Andre,
Perhaps I have more questions than answers here. I am developing an
application where I have objects representing users and I attach state
information ('datasets' that they are building etc.) to the user. I am
wondering whether there are any security concerns with what I plan to do.
(Not that there is anything on the system worth a cracker's attention, but it
is a matter of principle ;^)
In my design, user objects have a timestamp indicating their most recent
transaction. When a new user accesses the system, if the system is below a
threshold number of total users, I make a new user. If the system is above
the number of total users, I look for a user that is no longer active
(perhaps 1 hour since last transaction, in my application). If I can find
timed-out user, I clean up his resources and use that user object.
'Registered Users' are ones that can authenticate and therefore store
information on the server. I discard the state information of
non-authenticated users using the time-out policy described. (So I carry
state info on non-authenticated users for some period of time too, does that
seem OK?).
I use a search url with the user's ID as a means to associate users with http
transactions. I use armor-plated strings containing the user ID on forms he
POSTs for the same purpose. (I assume that the purpose of this armor-plating
stuff is to prevent others from forging a user-id and posting data... I need
to study this further.)
On Thursday 04 April 2002 01:56 am, A.Koehorst@xxxxxxxxxxxxxx wrote:
> James,
>
> I am not sure if there is a "standard" approach, but here is one that
> worked quite good for me in a computer based learning application (using
> patient management problems): i divided my application in several layers, i
> used cl-http only at the interface layer. I authenticated users in the
> interface layer and passed data about user and action to the application
> layer , which stored all necessary data in a user (history) model, where i
> had instances of my own user class, each of these corresponded to one
> instance of a cl-http user. I used a simple planner that looked at the
> action and the user model to determine a response (E.G. return requested
> data, ask user a question before returning the requested data, inform user
> that requested data had already been requested). I had one action (starting
> to see a new patient) which i could use to purge the data accumulated for
> one user, this way i could release resources. This also allowed my to
> retain state across sessions: a user could create a bookmark, log out, go
> to the bookmarked url a few days later, log in and go on where (s)he left.
>
> Andre
--
Best Regards,
- Peter
Peter Denno
National Institute of Standards and Technology,
Manufacturing System Integration Division,
100 Bureau Drive, Mail Stop 8260 Tel: +1 301-975-3595
Gaithersburg, MD, USA 20899-8260 FAX: +1 301-975-4694
|
