横断/運用基盤 / セッション制御

概要

fincs サービスの認証セッション・端末管理・バージョン更新検知・契約期限チェック・ログイン試行制限をまとめたセッション制御基盤。

主な構成要素:

• 同時ログイン端末数の制限: 1 ユーザーが同時に利用できる端末数を制限
• アプリのバージョン更新検知: 新バージョンが配信されたタイミングで内部的に検知し、画面リロードを促す
• 契約期限チェック: 会員の講座契約期限切れを定期的にチェックし、期限切れ後の不適切な閲覧を防止

主な利用想定は、不正利用防止（同時ログイン制限）、リリース後の最新版への自動誘導、契約期限切れ後の閲覧防止など。

同時ログイン制限: 会員・サブ講師は最大 2 台までの同時ログイン。メイン講師は対象外（端末制限なし）。3 台目以降の端末でログインすると、最も古い端末から自動的にログアウトされる仕組み（先入れ先出し）。CS で「身に覚えなくログアウトされた」相談時は同時利用端末数の確認を案内。

契約期限チェック: 会員がトーク画面を開いている間、定期的に契約状態をチェックし、期限切れが確認された時点で画面を自動リロードしてアクセス制限。タイミングは数十分〜半日単位で動作。

メンテナンスモードは未提供: メンテナンス時にユーザーに専用画面を表示する機能は未実装。リリース・障害対応時の運用は別経路で対応する。

利用シナリオ

シナリオ 1: 3 台目の端末でログインしたときの挙動

会員またはサブ講師が既に 2 台の端末でログイン中の状態で、3 台目の端末からログインしようとすると、最も古い端末が自動的にログアウト状態になる。3 台目のユーザーは正常にログイン継続可能で、押し出された端末は次回操作時にセッション切れとなり再ログインを求められる。

シナリオ 2: リリース直後のバージョン更新ダイアログ

新バージョンがリリースされると、ユーザーが画面を開いてしばらく経つと内部的に新バージョンを検知してダイアログを表示。「更新する」ボタンで画面リロードが走り、最新版に切り替わる。

シナリオ 3: 契約期限切れ後の自動リロード

会員がトーク画面を開いて利用していた状態で、契約期限が経過した場合、定期チェックで失効が確認された時点で画面が自動的にリロードされ、契約終了後のアクセスができなくなる。

シナリオ 4: ログイン連続失敗時の挙動

メール + パスワード認証で連続して失敗を繰り返した場合、内部的に失敗カウント・ロック予定時刻を記録。ただし現時点でロック判定の仕組みは完成途中のため、運用上のロック効果は限定的。

よくある失敗ケース

• 押し出された端末での操作: ログアウトされた端末で操作するとセッション切れエラー。再ログインを案内
• 契約終了後のトーク画面残留: 契約期限直後のタイミングで画面を開いている場合、定期チェックの周期次第で短時間アクセスできてしまうケースがある
• 更新ダイアログを閉じても再度表示される: 次回ポーリングタイミングで同じ新バージョン検知が走るため。「更新する」を選ばない限り表示が続く
• Redis 障害時のセッション制御不能: 内部のセッション情報を Redis で保持するため、Redis 障害時はセッション制御が機能しないリスクあり

利用可否（権限別）

横断軸

機能詳細（ふるまい）

同時ログイン制限

• 対象: 会員・サブ講師（メイン講師は対象外で台数制限なし）
• 上限: 同時 2 台までログイン可能（dev 環境は 3 台）
• 3 台目以降のログイン: 最も古い端末から自動ログアウトされる先入れ先出し方式
• 押し出された端末の検知: 内部で定期的にセッション継続をチェックし、押し出された端末は自動的にログアウト状態へ移行

バージョン更新検知

• 内部で定期的（約 1 時間周期）に最新バージョン情報をポーリング
• 起動時のバージョンと現行バージョンが不一致の場合、画面に更新ダイアログを表示
• 「更新する」ボタンで画面リロードが走り、最新版に切り替わる
• ユーザーが「後で」を選んだ場合、次のポーリングタイミングで再表示

契約期限チェック

• 会員がトーク画面を開いている間に動作
• 1 分タイマーで動作し、前回チェックから 12 時間経過時に契約情報を再取得
• 契約失効が確認された時点で画面を自動リロード
• 講師には契約概念がないため対象外

メンテナンスモード

• 現時点では未実装
• メンテナンス時にユーザーに専用画面を表示する機能は提供していない
• リリース・障害時のユーザー対応は別経路で運用

関連ドキュメント

• 関連 PSD:
  • 運営にお問い合わせください — 運営アドミン認証
  • 横断/運用基盤 / 通知基盤 — 通知基盤