Maintaining Session State in a VSP Application tutorial
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.