Sessions - civiform/civiform GitHub Wiki

This page explains how sessions work in CiviForm.

Related content

• Authentication providers
• Login and logout flows
• Session replay design doc
• Session timeout design doc
• Authentication in CiviForm - slides, recording

Concepts

• A session is a general web concept used to refer to a user's visit to a web site.
• A Play session is a construct that stores information about a user's session. It is stored client-side in a browser cookie in a signed JWT format. You can read your Play session by visiting the /dev/session URL in a non-prod CiviForm environment.
• A user profile or profile is a pac4j construct that stores information about a user. CiviForm uses pac4j's PlayCookieSessionStore to store the profile in the Play session. You can read your profile by visiting the /dev/profile URL in a non-prod CiviForm environment.

Sessions in CiviForm

CiviForm mainly uses the pac4j profile to store session-related content, such as the user's role (e.g. applicant, admin) and identity (e.g. name, email address). Profiles are created for both guest and logged-in users. A profie can be created two ways:

• The user visits a page covered by CiviFormProfileFilter, which automatically creates a guest profile for the user.
• The user logs in as an applicant or admin, and pac4j's callback endpoint creates the profile.

CiviForm sessions are client-side, which means the server is generally stateless. However, two features require server state:

• Enhanced OIDC logout (original design doc) requires storing a token for each session to send to the auth provider at logout time.
• Session replay prevention requires storing a session ID so that the session can be invalidated on logout.

Neither Play nor pac4j has a concept of session ID, so CiviForm generates one using UUID and stores it in the pac4j profile.