Authentication and Session Management#

Sure uses a cookie-based session authentication system built on Rails conventions. The three core pieces are: the Authentication controller concern (enforces auth on every request), the Current model (carries per-request context), and the ImpersonationSession model (supports admin impersonation with consent).

Request-Scoped Context: Current#

app/models/current.rb is a subclass of ActiveSupport::CurrentAttributes. It holds the active session, the user_agent, and the ip_address for each request.

The key accessors are 1:

Authentication Concern#

app/controllers/concerns/authentication.rb is included in ApplicationController and installs three before_action callbacks 2:

1. set_request_details — writes Current.user_agent and Current.ip_address from the request 3.
2. authenticate_user! — looks up a Session record via a signed :session_token cookie and assigns it to Current.session. Unauthenticated requests are redirected to new_session_url (or new_registration_url on self-hosted first boot) 4.
3. set_sentry_user — tags the Sentry scope with the current user when SENTRY_DSN is set 5.

Controllers that don't need authentication call skip_authentication (e.g., the sessions and registrations controllers).

Session creation writes a permanent, httponly signed cookie 6:

cookies.signed.permanent[:session_token] = { value: session.id, httponly: true }

Session Model#

app/models/session.rb is an ActiveRecord model that belongs to a User and, optionally, an ImpersonationSession via the active_impersonator_session association. The presence of active_impersonator_session on the session record is what makes Current.impersonated_user non-nil 7.

Admin Impersonation#

Impersonation is consent-based and restricted to super_admin users. The flow:

super admin creates request → impersonated user approves → super admin joins → actions logged → complete/leave

Model: ImpersonationSession enforces three hard constraints at the model layer 8:

• Impersonator must be a super_admin
• Impersonated user cannot be a super_admin
• A user cannot impersonate themselves

Status lifecycle: pending → in_progress → complete (or rejected) 9.

Controller: ImpersonationSessionsController orchestrates the workflow 10:

• create — super admin requests impersonation of a user
• join — super admin attaches the approved ImpersonationSession to their own Current.session
• leave — super admin detaches (sets active_impersonator_session: nil)
• approve / reject — the impersonated user accepts or declines
• complete — either party ends the session

The Impersonatable concern (app/controllers/concerns/impersonatable.rb) auto-logs each request to ImpersonationSessionLog (app/models/impersonation_session_log.rb) whenever an active impersonation session exists, capturing controller, action, path, HTTP method, IP, and user agent.

User Roles and Fixtures#

The application has four roles: guest, member, admin, and super_admin. Support staff (impersonators) are provisioned as super_admin 11.

Test fixtures in test/fixtures/users.yml pre-hash passwords using BCrypt::Engine::MIN_COST to keep test sign-in fast 12. All fixture users share the same password returned by user_password_test 13.

Test Helpers#

Integration / unit tests (ActiveSupport::TestCase, ActionDispatch::IntegrationTest):
sign_in(user) posts credentials to sessions_path to establish a real cookie-based session 14:

post sessions_path, params: { email: user.email, password: user_password_test }

System tests (ApplicationSystemTestCase):
sign_in(user) drives the actual login form via Capybara and waits for "Welcome back, #{user.first_name}" before continuing 15. login_as(user) is an alias 16.

sign_out clicks through the user menu 17.

Key Files#