posted on 3:12 PM, July 10, 2009
Session Management gives the developer a tool for maintaining state or caching useful user-specific data across different page requests. It is an optional feature of ExSite Webware.
Session data is stored in the global variable %session.
By default, the contents of this variable are cleared on every
request. To maintain the contents of this variable from request
to request, you need to enable Data Persistence. If you do
so, then data you place into %session on one page view will still be there on subsequent page views by the same user. Other users will see their own data in %session—in other words, the contents of this variable are private and unique for each visitor.
With data persistence, session data will persist as long as the user
stays active on the system. After one hour of
idle time, the session will be automatically purged from the
system. (Without data persistence, the session data will only
persist for the current request. In that case, %session is functionally equivalent to %share.)
Accessing Session Data
Session data are key=>value pairs that are stored in the %session hash.
You can store arbitrarily complicated data structures here, if
needed. Use any key names you like to index your data, but try to
keep them reasonably specific/unique to reduce the chances of colliding
with other data.
No special effort is required to initiate a session; ExSite will automatically set up the user's session as soon as it's needed (ie. when some data gets written to it). When programming, simply write to or read from the %session hash as needed. You can overwrite older session values, and delete session keys, as necessary. ExSite takes care of preserving that data for future requests.
ExSite stores the user's session ID in a cookie; the user must
accept this cookie for session management to work.
Session PerformanceSessions use the Persistent Data Store, which is faster than the back-end database. For this reason, it makes sense to store transient information about the visitor in the session rather than writing it to the database. Examples include:
Using Sessions for Authentication
If you are using sessions, it can be a small performance enhancement to move your system authentication logic over to the session model. This reduces database lookups when authenticating users, and will improve system performance. To use session-based authentication, use the following exsite.conf configuration parameter:
auth.type = session
When this happens, ExSite will store the user's authentication information
in the session data, so that it does not have to be looked up on each page
view. Since the session is cleared after 1 hour of idle time, users will automatically be logged out after that time.
Note that having an open session is not the same as being logged
in. Just because ExSite is preserving some information about your
visit, does not mean that you have been authenticated to a higher level
of website access. For example, online shoppers may have
information about their shopping cart preserved in their session,
without actually being logged in to the website.
Debugging & Inspecting SessionsSession data is kept in the Persistent Data Store. You can see the sessions if you launch the Persistent Data Store control panel. They are all prefixed with "session:" followed by the session ID (a unique hash code) for each visitor. Click the "inspect" link to view the data in that visitor's session. Click the "clear" button to erase the session (which will reset the visitor's state).
To join an active session using the ExSite debugger, define your session ID cookie to match the session you want to join:
./cgi -c 'ExSite_sessionID=0df7923bb6d80850efa5ac9c00a0dc87' -d 'SOME_URL'Then you can ignore the debugger's login prompt (hit return when asked).
best practices (5)
content management (12)
data handling (7)
graphic design (21)
html formatting (7)
plug-in modules (28)
visual tutorial (29)
web protocols (9)