Construct the wai-session middleware using the given storage backend and options. This is a convenient function that uses withSession, createState, sessionStore, getCookieName and createCookieTemplate.

Invalidate the current session ID (and possibly more, check ForceInvalidate). This is useful to avoid session fixation attacks (cf. http://www.acrossecurity.com/papers/session_fixation.pdf).

Which session IDs should be invalidated.

Note that this is not the same concept of invalidation as used on J2EE. In this context, invalidation means creating a fresh session ID for this user's session and disabling the old ID. Its purpose is to avoid session fixation attacks.

Construct the wai-session session store using the given state. Note that keys and values types are fixed.

As wai-session always requires a value to be provided, we return an empty ByteString when the empty session was not saved.

Create a cookie template given a state.

Since we don't have access to the Session, we can't fill the Expires field. Besides, as the template is constant, eventually the Expires field would become outdated. This is a limitation of wai-session's interface, not a serversession limitation. Other frontends support the Expires field.

Instead, we fill only the Max-age field. It works fine for modern browsers, but many don't support it and will treat the cookie as non-persistent (notably IE 6, 7 and 8).

Class for session data types that can be used as key-value stores.

Set the name of cookie where the session ID will be saved. Defaults to "JSESSIONID", which is a generic cookie name used by many frameworks thus making it harder to fingerprint this implementation.

Set the name of the session variable that keeps track of the logged user.

This setting is used by session data types that are Map-alike, using a lookup function. However, the IsSessionData instance of a session data type may choose not to use it. For example, if you implemented a custom data type, you could return the AuthId without needing a lookup.

Defaults to "_ID" (used by yesod-auth).

Set the idle timeout for all sessions. This is used both on the client side (by setting the cookie expires fields) and on the server side (the idle timeout is enforced even if the cookie expiration is ignored). Setting to Nothing removes the idle timeout entirely.

"[The idle timemout] defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID." (Source)

Defaults to 7 days.

Set the absolute timeout for all sessions. This is used both on the client side (by setting the cookie expires fields) and on the server side (the absolute timeout is enforced even if the cookie expiration is ignored). Setting to Nothing removes the absolute timeout entirely.

"[The absolute timeout] defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session." (Source)

Defaults to 60 days.

Set the timeout resolution.

We need to save both the creation and last access times on sessions in order to implement idle and absolute timeouts. This means that we have to save the updated session on the storage backend even if the request didn't change any session variable, if only to update the last access time.

This setting provides an optimization where the session is not updated on the storage backend provided that:

• No session variables were changed.
• The difference between the current time and the last saved access time is less than the timeout resolution.

For example, with a timeout resolution of 1 minute, every request that does not change the session variables within 1 minute of the last update will not generate any updates on the storage backend.

If the timeout resolution is Nothing, then this optimization becomes disabled and the session will always be updated.

Defaults to 10 minutes.

Set whether by default cookies should be persistent (True) or non-persistent (False). Persistent cookies are saved across browser sessions. Non-persistent cookies are discarded when the browser is closed.

If you set cookies to be persistent and do not define any timeouts (setIdleTimeout or setAbsoluteTimeout), then the cookie is set to expire in 10 years.

Defaults to True.

Set whether cookies should be HTTP-only (True) or not (False). Cookies marked as HTTP-only ("HttpOnly") are not accessible from client-side scripting languages such as JavaScript, thus preventing a large class of XSS attacks. It's highly recommended to set this attribute to True.

Defaults to True.

Set whether cookies should be mared "Secure" (True) or not (False). Cookies marked as "Secure" are not sent via plain HTTP connections, only via HTTPS connections. It's highly recommended to set this attribute to True. However, since many sites do not operate over HTTPS, the default is False.

Defaults to False.

The server-side session backend needs to maintain some state in order to work:

• A nonce generator for the session IDs.
• A reference to the storage backend.
• The name of cookie where the session ID will be saved (setCookieName).
• Authentication session variable (setAuthKey).
• Idle and absolute timeouts (setIdleTimeout and setAbsoluteTimeout).
• Timeout resolution (setTimeoutResolution).
• Whether cookies should be persistent (setPersistentCookies), HTTP-only (setHTTPOnlyCookies) and/or secure (setSecureCookies).

Create a new State using createState.