• Info
• Initial State
• View Source
• Run

Maintaining Session State in a VSP Application

VS-U-2 Basics

Url poisoning example

The default URL poisoning scheme

• There is an authentication function that restores the session variables from a session table.
• There is a post processing function to save the session variables into a session table.
• An authentication function will try to get a URL parameter named "sid", if there is a session table row corresponding to it.
• The state of session variables is read into memory with connection_vars_set().
• The post processing function updates the session table, saving all session variables available with connection_vars().

Example Description

• Using the built-in session table this web application saves the state between sessions.
• It has a front page with a two links "register" and "login".
• The register page will ask for the user id and for a password.
• The login page will ask for user id and password which are checked against an application dependant users table.
• Both pages will do a redirect message with the newly generated session id, to the default application page.
• The application pages (except front, login and register pages) can be placed under a separate directory.
• The directory containing the VSP application must be setup as executable with authentication and post processing hooks defined.
• The redirection to the application pages is made with URL parameter "sid" (the session id).
• The session id must be transferred between pages for the restoration of session variables.
• Each load of the default application page will restore the session variables, and will display the number increased by one.
• If the session expires, a redirect to the login page will be performed.

Step by step overview

The following sections describe the complete set of steps to make the application work. Most of this details also apply to the cookie and digest examples.

Authentication hook

• The authentication hook will get the 'sid' parameter using the get_keyword().
• If there is no row in the session table, it redirects to the login page.
• If a row exists, then increase the expiry time, and restore the session variables with connection_vars_set().
• If the authentication hook gets a 'logoff', then the session record is removed from the session table. The browser is redirected to the login page.

Post processing function

• The 'sid' is read from session variables using connection_get(), as this is faster than from the URL parameters.
• Check for change of the session variables with connection_is_dirty().
• If there is a change then serialize and store them into the session table. All variables are read with connection_vars().
• At the end of the post-processing hook clear the in-memory variables to avoid reading from other HTTP client by using connection_vars_set(null).

Login, Default & Registration pages

• The login page will check user & password against user-defined table (APP_USER) and if it matches, the new session will be created.
• When starting a new session, the 'sid' connection variable is also setup to be available in the post-processing hook.
• After a new session is done, there is a redirect using the header 'Location' to the default page.
• Note the Location URL contains the 'sid' parameter' (see line 61 of vs_u_2.sql)
• When the default page is called the authentication hook is already executed and session variables are in memory.
• Therefore it is only necessary to get with connection_get() and set (if needed) with connection_set().
• In this example, there is a 'ctr' variable that is a counter. It increases with each page reload.
• The logout link passes another URL parameter 'logoff', this is also handled in the authentication hook.