DBベースのDeviseを利用したログイン処理や、管理者によるユーザー成りすましログイン時に、認証情報やセッション情報がどのように保持・管理されているのかを改めて整理してみました。

本検証で利用した主なGem

• devise – ユーザー認証機能
• activerecord-session_store – DBベースのセッション管理

各種設定

セッション関連の設定概要

• セッションストア: active_record_store（DBベース）
• シリアライザー: :json
• セッションキー: _devise_project_session
• 設定ファイル:
  • config/initializers/session_store.rb – セッションストアの設定
    Rails.application.config.session_store :active_record_store, key: '_devise_project_session'
    
    
  • config/application.rb – シリアライザーの設定 # Configure session serializer ActiveRecord::SessionStore::Session.serializer = :json

:jsonシリアライザー

• 内部的にはRubyのJSONモジュール（parse / generate）を使用
• DB保存値は、データーベースの種類や参照方法に依存し、Base64エンコードされているケースと生データがそのまま入っているケースに分かれる。
  • SQLite3の場合、sessions.dataにBase64エンコードを実行した値が入っていた
    • Rails console経由では自動的にデシリアライズされて人間が読める形のHashとして参照可能
  • PostgreSQLの場合、sessions.dataにBase64エンコードされてない値が入っていた
    • sessions.data はSQLのWHERE句で検索可能
    • DB登録値を人間が直接みても把握しやすい
• SQLite3等のBase64エンコードされた値が登録されている場合でも、Rails console経由では自動的にデシリアライズされて人間が読める形のHashとして参照できる

成りすましログイン実装

実装方法

今回は devise_masquerade Gem は使用せず、独自に成りすましログインを実装しています。

コントローラー

管理者用の成りすまし処理は、専用コントローラー
app/controllers/admins/masquerade_controller.rb
にて実装

• create アクション: ユーザーとしてなりすましログイン
  • session[:admin_id] に管理者IDを保存
  • sign_in(user, scope: :user) でユーザーとしてログイン
  • 管理者とユーザーの両方のセッションを同時に保持
• back アクション: 管理者に戻る
  • session[:admin_id] を削除
  • sign_out(:user) でユーザーからログアウト
  • 管理者は最初からログインしたままなので、再ログイン不要

動作の仕組み

1. 管理者がユーザーとして成りすましログインすると、session[:admin_id]に管理者IDを保存
2. Deviseのsign_inメソッドでscope: :userを指定してユーザーとしてログイン
3. 管理者とユーザーのセッションが同時に保持される（Wardenの機能）
4. 管理者に戻る際は、session[:admin_id]を削除し、ユーザーからログアウト
5. 管理者のセッションは保持されているため、自動的に管理者としてログインした状態に戻る

挙動の確認

通常ログイン時の挙動

ユーザーとしてログインした際に、ブラウザ（Cookie）およびDB（sessionsテーブル）に保持される情報を確認します。

1. ログアウト状態でトップページにアクセスしてユーザーログイン画面に移動

cookie情報:

2. ユーザーとしてログイン

2-1. Remember me機能を利用しない場合

cookie情報:

DB情報:

2-2. Remember me機能を利用した場合

cookie情報:

DB情報:

3. ログアウト実行

3-1. Remember me機能を利用しない場合

cookie情報:

DB情報:

3-2. Remember me機能を利用した場合

cookie情報:

DB情報:

代行ログイン時の挙動

管理者がユーザーとして成りすましログインを行った際の、ブラウザ側の保持情報とDB側の情報を確認します。
なおこちらは、ログイン前もDB情報を確認しています。

1. ログアウト状態でトップページにアクセスして管理者ログイン画面に移動

cookie情報:

DB情報:

2. 管理者としてログイン

※ Remember me機能を利用しない場合のみ実施

cookie情報:

DB情報:

3. ユーザーで成りすましログイン

cookie情報:

DB情報:

4. 成りすましユーザーからログアウトして管理者に戻る

cookie情報:

DB情報:

5. 管理者からもログアウトする

cookie情報:

DB情報:

検証結果

ログイン・ログアウト・成りすましといった操作のたびに、sessions.id, sessions.session_idや、ブラウザのセッション情報が変化することで、不正ログインを防ぐ仕組みになっていることが確認できました。

ユーザーサイドから考えると、普段からきちんとログアウトしておくのが重要であると再認識しました。

運用時のTips

成りすましログイン後にログアウトを行わず、別のユーザーへ続けて成りすましログインした場合の挙動

先に成りすました状態を維持したまま、後続のユーザー情報でセッション内容が更新される挙動が確認できました。
セッションデータ内のユーザー識別情報（warden.user.user.key）が、後続の成りすましログインによって上書きされています。

{
  "value": {
    "flash": {
      "discard": [],
      "flashes": {
        "notice": "user2@example.comとしてログインしました"
      }
    },
    "warden.user.admin.key": [[1], "$2a$12$7WI0p3xhsuv.PGH9eAkcoe"],
    "_csrf_token": "Ec7oxb5a3ss3VbRTRy-WfV1SO3VanJau-WEmcG-PJME",
    "admin_id": 1,
    "warden.user.user.key": [[2], "$2a$12$CRQBRFPsBNpJkcxBfPaMYu"]
  }
}

sessions テーブルが肥大化した場合の対処

ActiveRecord Session Store の公式ドキュメントでも言及されていますが、期限切れのセッションや不要なセッションデータが蓄積し続けるのを防ぐため、本番環境ではセッション削除用のタスクを定期的に実行することが推奨されています。
デフォルト設定では、一定期間（例：30日）更新されていないセッションが削除対象となり、この期間は環境変数によって調整可能です。

ActiveRecord Session Store 公式ドキュメント（2026年1月閲覧）：
https://github.com/rails/activerecord-session_store/blob/master/README.md#installation