Session management

HTTP is a stateless protocol. This means that a web server processes each HTTP request as an isolated unit. The server does not retain any knowledge about the state or outcome of a previous request from the same user. With the session management, the CXP core provides a mechanism with which you can temporarily store and retrieve user-specific values. These values can be stored on your website for the duration of the user's session or even for a longer period of time, if required.

For technical reasons, the CXP session management requires that the browser allows cookies to be set. Cookies are used for storing a unqiue value (UUID) on the browser side, which is then used for identifying the client in subsequent requests, and for retrieving or storing session-specific data.

The session management in CXP is fully automated and transparent. You do not need to care about when data needs saving, for example. Just assign your session data as values of members of the :session object, or read these members for retrieving the information. The CXP core uses dbf/cdx tables for storing the session data under the cxp-data directory of your website. You can configure the storage manager used for maintaining session information in your global.config or in your application.config file. The latter file can be used to isolate different web applications from your website in terms of session management for performance or security reasons. However, the default configuration should be perfect in most if not all cases.

The following two CXP pages illustrate the usage of session data. The session-form.cxp allows you to enter your name in a form and uses the session-save.cxp page below for storing this information in the session object. Whenever the session-form.cxp page is requested again, it checks if session data has been defined. If so, the entered information is displayed, the session data is reset and a link is displayed to start over from the beginning.

<!-- session-form.cxp --> 
<!DOCTYPE html> 
<html> 
<head> 
 <title>Session-Sample</title> 
</head> 
<body> 
@IF(::session:user==NIL) 
  <!-- No session data defined: create a HTML form to get some data --> 
  <h1>Session Basics</h1> 
  <form action="./session-save.cxp" method="get"> 
    Username:<input type="text" name="user" /> 
    <input type="submit" value="Submit" /> 
  </form> 
@ELSE 
  <!-- Session data defined: dump the information and reset --> 
  <h1>Session data from session object:</h1> 
  <h2>User:@(::session:user)<br> 
  Entered at:@(::session:time)</h2> 
  <a href='./session-form.cxp'>Click here to enter new session data</a> 
@::session:user := NIL; ::session:time := NIL 
@ENDIF 
</body> 
</html>

<!-- session-save.cxp --> 
<!DOCTYPE html> 
<html> 
<head> 
 <title>Session-Sample</title> 
</head> 
<body> 
<% 
   // Assigning a value to a session variable not only stores the value, but 
   // also creates the member if it doesn't exist yet. 
   ::session:user := ::params:user 
   ::session:time := Time() 
%> 
   <h1>Form data stored in session object!</h1> 
   <a href='./session-form.cxp'>Click here to load session data</a> 
</body> 
</html>

The default session timeout is 15 minutes. You can configure this timeout by adding a section to your global.config or application.config file. Using the application.config file allows you to manage your sesssion timeouts independently on an per-application level.

The code below shows the default session configuration. The CxpCookieSessionManager is currently the only provider for CXP. However, the CXP architecture allows the development of your own providers. The timeout is 45 minutes.

<sessionmanager 
provider = "CxpCookieSessionManager" 
timeout  = "45"/>

If a session timeout elapses, the information available in the session object is gone and can no longer be retrieved. In fact, the storage may already have been reused by this time. With each new request the session timer is reset. This process is called slicing. As outlined previously, the CXP session manager tracks automatically if data has been assigned to the :session object. However, there are situations where this automated tracking unable to detect changes. This the case if your :session references an instance object. If you change values in the member variables of this instance object, the CXP session manager can not detect data changes. Consequently, your changes are lost. To avoid this, you can explicit mark the session as changed using the :setChanged( .T. ) method of the session object. Doing so prompts the session manager to persist the :session information regardless of whether any changes are detected.

Sometimes the opposite is required, however. There are situations where you need the session timer to not be reset when a request is performed by the browser. An automated request from your web application for tracking some state would be such a use case; this request would reset the session timer permanently, even though the user did not perform any action. In cases such as this, use the :session:noSlice() method at the beginning of your CXP page. This way, your CXP page does not reset the session timer when it is requested, and therefore no slicing occurs.

If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.

Session management Foundation