Forum OpenACS Q&A: How to keep trace of server-side state?

Collapse
Posted by Ke Wang on
When I am writing my website, I want to keep track of where is the
user at. For examaple, when the user request page 2, I can check
whether he has finished requested operation on page 1.

I do not want to use cookie. Is there any other way to do it? How
about I create some table to store the current state of the user? If
I want to have the state information encrypted using my secret key,
what should I do?

Thank you very much!!

Collapse
Posted by Jonathan Ellis on
Sure, you could store this in a table. You could define a proc like
proc_doc ad_track_user { } {
    records the script  the user is in
} {
    set u_id [ad_get_user_id]
    set u_script [info script]
    db_dml track_i "insert into user_tracking(user_id, script, when) values (:u_id, :u_script, now())"
}
The reason most people don't do this is that depending on your user load it could be pretty hard on your db to do an insert/update with every page load. For a low traffic site though this could be fine. For something more advanced, try the ASJ clickstream article.
Collapse
Posted by Patrick Giagnocavo on
I would think that one way to solve this would be to use sessionid's encoded in the URL.

First request: give a sessionid, store it in a nsv shared variable, redirect to URL + sessionid.

Second request:  the sessionid is already there, so you store the info and serve the page.

Advantages:  no cookies, and you can expire sessions when you want them to (never expire, expire in 4 hours, etc.).

Disadvantages:  you have to parse the HTML pages one way or another and modify the URLs to have the sessionid in the links, OR, do the first request/second request each time a new page is requested.

Collapse
Posted by Luke Pond on
Look at the tcl api documentation for ad_set_client_property and ad_get_client_property. OpenACS4 already has session management built in, and these procedures keep track of variables for each session. Depending on what you use for the -persistent and -deferred flags, they can be written to the database immediately, when the session closes, or not at all.

I'd also recommend that newcomers to OpenACS4 read the Request Processor Design document that describes all the data available from the ad_conn command. Among other things, this is your interface to the session_id and user_id cookies that the system is managing on your behalf.