Re: retaining state within the server

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, [email protected] 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