Apache Module mod_session

Summary

This module provides support for a server wide per user session interface. Sessions can be used for keeping track of whether a user has been logged in, or for other per user information that should be kept available across requests.

Sessions may be stored on the server, or may be stored on the browser. Sessions may also be optionally encrypted for added security. These features are divided into several modules in addition tomod_session;mod_session_crypto,mod_session_cookie andmod_session_dbd. Depending on the server requirements, load the appropriate modules into the server (either statically at compile time or dynamically via theLoadModule directive).

Sessions may be manipulated from other modules that depend on the session, or the session may be read from and written to using environment variables and HTTP headers, as appropriate.

Topics

• What is a session?
• Who can use a session?
• Keeping sessions on the server
• Keeping sessions on the browser
• Basic Examples
• Session Privacy
• Cookie Privacy
• Session Support for Authentication
• Integrating Sessions with External Applications

Directives

• Session
• SessionEnv
• SessionExclude
• SessionExpiryUpdateInterval
• SessionHeader
• SessionInclude
• SessionMaxAge

Bugfix checklist

• httpd changelog
• Known issues
• Report a bug

See also

• mod_session_cookie
• mod_session_crypto
• mod_session_dbd
• Comments

What is a session?

At the core of the session interface is a table of key and value pairs that are made accessible across browser requests. These pairs can be set to any valid string, as needed by the application making use of the session.

The "session" is aapplication/x-www-form-urlencoded string containing these key value pairs, as defined by theHTML specification.

The session can optionally be encrypted and base64 encoded before being written to the storage mechanism, as defined by the administrator.

Who can use a session?

The session interface is primarily developed for the use by other server modules, such asmod_auth_form, however CGI based applications can optionally be granted access to the contents of the session via the HTTP_SESSION environment variable. Sessions have the option to be modified and/or updated by inserting an HTTP response header containing the new session parameters.

Keeping sessions on the server

Apache can be configured to keep track of per user sessions stored on a particular server or group of servers. This functionality is similar to the sessions available in typical application servers.

If configured, sessions are tracked through the use of a session ID that is stored inside a cookie, or extracted from the parameters embedded within the URL query string, as found in a typical GET request.

As the contents of the session are stored exclusively on the server, there is an expectation of privacy of the contents of the session. This does have performance and resource implications should a large number of sessions be present, or where a large number of webservers have to share sessions with one another.

Themod_session_dbd module allows the storage of user sessions within a SQL database viamod_dbd.

Keeping sessions on the browser

In high traffic environments where keeping track of a session on a server is too resource intensive or inconvenient, the option exists to store the contents of the session within a cookie on the client browser instead.

This has the advantage that minimal resources are required on the server to keep track of sessions, and multiple servers within a server farm have no need to share session information.

The contents of the session however are exposed to the client, with a corresponding risk of a loss of privacy. Themod_session_crypto module can be configured to encrypt the contents of the session before writing the session to the client.

Themod_session_cookie allows the storage of user sessions on the browser within an HTTP cookie.

Basic Examples

Creating a session is as simple as turning the session on, and deciding where the session will be stored. In this example, the session will be stored on the browser, in a cookie calledsession.

Session OnSessionCookieName session path=/

The session is not useful unless it can be written to or read from. The following example shows how values can be injected into the session through the use of a predetermined HTTP response header calledX-Replace-Session.

Session OnSessionCookieName session path=/SessionHeader X-Replace-Session

The header should contain name value pairs expressed in the same format as a query string in a URL, as in the example below. Setting a key to the empty string has the effect of removing that key from the session.

#!/bin/bashecho "Content-Type: text/plain"echo "X-Replace-Session: key1=foo&key2=&key3=bar"echoenv

If configured, the session can be read back from the HTTP_SESSION environment variable. By default, the session is kept private, so this has to be explicitly turned on with theSessionEnv directive.

Session OnSessionEnv OnSessionCookieName session path=/SessionHeader X-Replace-Session

Once read, the CGI variableHTTP_SESSION should contain the valuekey1=foo&key3=bar.

Session Privacy

Using the "show cookies" feature of your browser, you would have seen a clear text representation of the session. This could potentially be a problem should the end user need to be kept unaware of the contents of the session, or where a third party could gain unauthorised access to the data within the session.

The contents of the session can be optionally encrypted before being placed on the browser using themod_session_crypto module.

Session OnSessionCryptoPassphrase secretSessionCookieName session path=/

The session will be automatically decrypted on load, and encrypted on save by Apache, the underlying application using the session need have no knowledge that encryption is taking place.

Sessions stored on the server rather than on the browser can also be encrypted as needed, offering privacy where potentially sensitive information is being shared between webservers in a server farm using themod_session_dbd module.

Cookie Privacy

The HTTP cookie mechanism also offers privacy features, such as the ability to restrict cookie transport to SSL protected pages only, or to prevent browser based javascript from gaining access to the contents of the cookie.

Standard cookie parameters can be specified after the name of the cookie, as in the example below.

Session OnSessionCryptoPassphrase secretSessionCookieName session path=/private;domain=example.com;httponly;secure;

In cases where the Apache server forms the frontend for backend origin servers, it is possible to have the session cookies removed from the incoming HTTP headers using theSessionCookieRemove directive. This keeps the contents of the session cookies from becoming accessible from the backend server.

Session Support for Authentication

As is possible within many application servers, authentication modules can use a session for storing the username and password after login. Themod_auth_form saves the user's login name and password within the session.

Session OnSessionCryptoPassphrase secretSessionCookieName session path=/AuthFormProvider fileAuthUserFile "conf/passwd"AuthType formAuthName "realm"#...

See themod_auth_form module for documentation and complete examples.

Integrating Sessions with External Applications

In order for sessions to be useful, it must be possible to share the contents of a session with external applications, and it must be possible for an external application to write a session of its own.

A typical example might be an application that changes a user's password set bymod_auth_form. This application would need to read the current username and password from the session, make the required changes to the user's password, and then write the new password to the session in order to provide a seamless transition to the new password.

A second example might involve an application that registers a new user for the first time. When registration is complete, the username and password is written to the session, providing a seamless transition to being logged in.

Apache modules

Modules within the server that need access to the session can use themod_session.h API in order to read from and write to the session. This mechanism is used by modules likemod_auth_form.

CGI programs and scripting languages

Applications that run within the webserver can optionally retrieve the value of the session from theHTTP_SESSION environment variable. The session should be encoded as aapplication/x-www-form-urlencoded string as described by theHTML specification. The environment variable is controlled by the setting of theSessionEnv directive. The session can be written to by the script by returning aapplication/x-www-form-urlencoded response header with a name set by theSessionHeader directive. In both cases, any encryption or decryption, and the reading the session from or writing the session to the chosen storage mechanism is handled by themod_session modules and corresponding configuration.

Applications behindmod_proxy

If theSessionHeader directive is used to define an HTTP request header, the session, encoded as aapplication/x-www-form-urlencoded string, will be made available to the application. If the same header is provided in the response, the value of this response header will be used to replace the session. As above, any encryption or decryption, and the reading the session from or writing the session to the chosen storage mechanism is handled by themod_session modules and corresponding configuration.

Standalone applications

Applications might choose to manipulate the session outside the control of the Apache HTTP server. In this case, it is the responsibility of the application to read the session from the chosen storage mechanism, decrypt the session, update the session, encrypt the session and write the session to the chosen storage mechanism, as appropriate.

SessionDirective

TheSession directive enables a session for the directory or location container. Further directives control where the session will be stored and how privacy is maintained.

SessionEnvDirective

If set toOn, theSessionEnv directive causes the contents of the session to be written to a CGI environment variable calledHTTP_SESSION.

The string is written in the URL query format, for example:

SessionExcludeDirective

TheSessionExclude directive allows sessions to be disabled relative to URL prefixes only. This can be used to make a website more efficient, by targeting a more precise URL space for which a session should be maintained. By default, all URLs within the directory or location are included in the session. TheSessionExclude directive takes precedence over theSessionInclude directive.

SessionExpiryUpdateIntervalDirective

TheSessionExpiryUpdateInterval directive allows sessions to avoid the cost associated with writing the session each request when only the expiry time has changed. This can be used to make a website more efficient or reduce load on a database when usingmod_session_dbd. The session is always written if the data stored in the session has changed or the expiry has changed by more than the configured interval.

Setting the interval to zero disables this directive, and the session expiry is refreshed for each request.

This directive only has an effect when combined withSessionMaxAge to enable session expiry. Sessions without an expiry are only written when the data stored in the session has changed.

SessionHeaderDirective

TheSessionHeader directive defines the name of an HTTP response header which, if present, will be parsed and written to the current session.

The header value is expected to be in the URL query format, for example:

Where a key is set to the empty string, that key will be removed from the session.

SessionIncludeDirective

TheSessionInclude directive allows sessions to be made valid for specific URL prefixes only. This can be used to make a website more efficient, by targeting a more precise URL space for which a session should be maintained. By default, all URLs within the directory or location are included in the session.

SessionMaxAgeDirective

TheSessionMaxAge directive defines a time limit for which a session will remain valid. When a session is saved, this time limit is reset and an existing session can be continued. If a session becomes older than this limit without a request to the server to refresh the session, the session will time out and be removed. Where a session is used to stored user login details, this has the effect of logging the user out automatically after the given time.

Setting the maxage to zero disables session expiry.