Class: SessionsController

Inherits:
ApplicationController
  • Object
show all
Defined in:
app/controllers/sessions_controller.rb

Instance Method Summary collapse

Instance Method Details

#create ⇒ Object 



7
8
9
10
11
12
13
14
15
16
 
# File 'app/controllers/sessions_controller.rb', line 7

def create
  user = User.find_by(email: params[:email])
  if user&.authenticate(params[:password])
    set_app_session(user)
    redirect_to root_path, notice: "Welcome back, #{user.display_name}!"
  else
    flash.now[:alert] = "Invalid email or password."
    render :new, status: :unprocessable_entity
  end
end

#destroy ⇒ Object 



44
45
46
47
 
# File 'app/controllers/sessions_controller.rb', line 44

def destroy
  clear_app_session
  redirect_to , notice: "Logged out."
end

#new ⇒ Object 



4
5
 
# File 'app/controllers/sessions_controller.rb', line 4

def new
end

#sso_continue ⇒ Object

POST /sso_continue — form-based SSO from login page button



35
36
37
38
39
40
41
42
 
# File 'app/controllers/sessions_controller.rb', line 35

def sso_continue
  return redirect_to  unless sso_user_available?

  authenticate_sso_user!
rescue StandardError => e
  create_error_log(e)
  redirect_to , alert: "Could not continue session. Please log in."
end

#sso_login ⇒ Object

GET /sso_login — one-click SSO entry point (linked from hub app nav).

OPSEC-016: this previously called authenticate_sso_user! directly, mutating the session on a GET. GETs are not CSRF-covered and are prefetchable (browser prefetch, <img>, <link rel=prefetch>), so an XSS on any *.mcritchie.studio subdomain could write session and a forged GET /sso_login would silently start a session as that user. It now only redirects to the login page — the session mutation happens exclusively via the CSRF-protected POST /sso_continue (“Continue as …” button rendered there when sso_user_available?).



28
29
30
31
32
 
# File 'app/controllers/sessions_controller.rb', line 28

def 
  return redirect_to root_path if logged_in?

  redirect_to 
end