AuthManager

and
SessionManager

SessionManager

Authenticate the user based on information that's contained in every request

E.g. cookies, OAuth (Authentication HTTP header)

AuthManager

Authenticate the user through some login process, and set up a session (so further requests can be handled by SessionManager)

SessionManager design goals

  • Detach session handling from PHP (which has the built-in assumption that all sessions are based on cookies)
  • Make session initialization timeline deterministic

SessionManager

  • Core and extensions provide a list of SessionProvider objects
  • Each session provider gets asked via SessionProvider::provideSessionInfo(WebRequest), might return a SessionInfo
  • mutable providers can persist and unpersist the session identifier in the request (e.g. set/delete cookies), immutable providers only read it

A minimal example

SessionManager

Authenticate the user based on information that's contained in every request

E.g. cookies, OAuth (Authentication HTTP header)

AuthManager

Authenticate the user through some login process, and set up a session (so further requests can be handled by SessionManager)

AuthManager design goals

  • Allow multiple login providers to coexist
  • Allow login methods that are not based on submitting username+password
  • Handle account linking (not fully finished yet)
  • Allow multi-step login process

AuthManager

  • Core and extensions provide three groups of handlers:
  • PreAuthenticationProvider: do checks before determining the user's identity (eg. prevent login from blocked IP)
  • PrimaryAuthenticationProvider: determine user identity
  • SecondaryAuthenticationProvider: do checks that require knowing who the user is (e.g. prevent login from blocked account)
  • All pre- and secondary providers will be queried, but only one primary provider

Control flow (simplified)

  • Manager gets a list of AuthenticationRequest objects
    getAuthenticationRequests
  • Form is presented to the user
  • Request objects updated with user data
  • All providers have a chance to reject
    testForAuthentication
  • Primary authentication providers handle the requests
    beginAuthentication, continueAuthentication
  • Secondary authentication providers handle the requests
    beginAuthentication, continueAuthentication
  • Post-authentication callbacks
    postAuthentication

Control flow (simplified)

begin/continueAuthentication in detail:

  • provider can return ABSTAIN, PASS, FAIL, UI, REDIRECT
  • ABSTAIN/PASS/FAIL: this provider is finished, continue to next one or abort
  • UI: create a new form with a new set of form fields; provider will be called again when it's submitted
  • REDIRECT: instead of showing form fields, send the user to some external page, which returns the data as URL query parameters when redirecting the user back (e.g. login with your Google account)

Resources

Made with Slides.com