Documentation

Construct the server-side session backend using the given storage backend.

Example usage for the Yesod scaffold using serversession-backend-persistent:

import Web.ServerSession.Backend.Persistent (SqlStorage(..))
import Web.ServerSession.Frontend.Yesod (simpleBackend)

instance Yesod App where
  ...
  makeSessionBackend = simpleBackend id . SqlStorage . appConnPool
  -- Do not forget to add migration code to your Application.hs!
  -- Please check serversession-backend-persistent's documentation.
  ...

For example, if you wanted to disable the idle timeout, decrease the absolute timeout to one day and mark cookies as "Secure", you could change that line to:

  makeSessionBackend = simpleBackend opts . SqlStorage . appConnPool
    where opts = setIdleTimeout Nothing
               . setAbsoluteTimeout (Just $ 60*60*24)
               . setSecureCookies True

This is a simple version of backend specialized for using SessionMap as SessionData. If you want to use a different session data type, please use backend directly (tip: take a peek at this function's source).

Construct the server-side session backend using the given state. This is a generalized version of simpleBackend.

In order to use the Yesod frontend, you SessionData needs to implement IsSessionMap.

Class for session data types meant to be used with the Yesod frontend. The only session interface Yesod provides is via session variables, so your data type needs to be convertible from/to a Map of Text to ByteString.

Create a cookie for the given session.

The cookie expiration is set via nextExpires. Note that this is just an optimization, as the expiration is checked on the server-side as well.

Fetch the SessionId from the cookie with the given name. Returns Nothing if:

• There are zero cookies with the given name.
• There is more than one cookie with the given name.

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).

Note that the invalidate does not occur when the call to this action is made! The sessions will be invalidated on the end of the handler processing. This means that later calls to forceInvalidate on the same handler will override earlier calls.

This function works by setting a session variable that is checked when saving the session. The session variable set by this function is then discarded and is not persisted across requests.