Q&A
リクエストトークンとリフレッシュトークンの実装、期限は有名どころのサービスの真似をするだけで良いと思いますが
未調査だったら検索してみたらどうでしょう？
それとredisを使う事とランニングコストの直接の関係はありませんが、その点に勘違いはしていない上でランニングコストが上がる設計を考えていますか？
前提・実現したいこと
Form認証で、セッションIDをCookieに保存するような会員制Webアプリケーションを作成しています。
Webアプリケーションの場合、必ずログアウト操作が行われるとは限りません。
下記の構成で、生成したセッションIDは、いつ破棄するのが一般的でしょうか。
処理の流れ
- クライアント：ログインリクエスト。
- サーバー ：DBからパスワードを取得、検証。セッションIDをDBに登録し、クライアントへセッションIDを付加したレスポンス。
- クライアント：リクエスト。
- サーバー ：DBからセッションIDに紐づくユーザー情報を取得、検証。レスポンス。
（以降は、３と４を繰り返します。）
構成
AWSで、以下の構成としています。
Nginx + uWSGI + Flaskです。
RDSは、Amazon RDS for MySQLです。
アプリケーションDBとセッションDBと兼用です。
補足情報（FW/ツールのバージョンなど）
調査したところ、Redisのようなインメモリデータベースを採用することで、
セッションIDに有効期限を決め、自動的に破棄してくれるようですが、
ランニングコストの関係上、当面は採用したくないと考えています。
ご返信いただきありがとうございます。
>リクエストトークンとリフレッシュトークンの実装、期限は有名どころのサービスの真似をするだけで>良いと思いますが
>未調査だったら検索してみたらどうでしょう？
初めてWebサービスを作ろうとしていて、無知なことばかりで、すいません。
リクエストトークンとリフレッシュトークンについては、調べてみます。
もし参考になるサイトや本がありましたら、教えていただけないでしょうか。
>それとredisを使う事とランニングコストの直接の関係はありませんが、その点に勘違いはしていない上>でランニングコストが上がる設計を考えていますか？
上記構成に加えて、セッションDBとして、Amazon ElastiCacheなどを利用することで、ランニングコストが上がるというのは、間違った認識ということでしょうか。（まったく検討違いなことを言っていたら、申し訳ありません。）
参考は特に無いです。ただし丸々OAuthの実装をする訳ではないので、そこら辺はうまく解釈してください。ログイン状態でも個人情報の書き換え権限が無ければ良いとか（書き換える際にパスワード要求）とか、都合よくWEBで使えるように解釈出来ると思います。
redisというのはnginxと同じでただのサーバーミドルウェアですから、redisを使う＝ec2に入れて使うなら追加コストはないという意味です。
Amazon ElastiCacheを使うのはまた別問題です。
ご返信いただきありがとうございます。
>参考は特に無いです。ただし丸々OAuthの実装をする訳ではないので、そこら辺はうまく解釈してくだ>さい。ログイン状態でも個人情報の書き換え権限が無ければ良いとか（書き換える際にパスワード要求）とか、都合よくWEBで使えるように解釈出来ると思います。
調べてみます。ありがとうございました。
>redisというのはnginxと同じでただのサーバーミドルウェアですから、redisを使う＝ec2に入れて使う>なら追加コストはないという意味です。
>Amazon ElastiCacheを使うのはまた別問題です。
確かにそのパターンではコストは上がらないですね。
セッション管理を外部DBにした理由として、EC2が停止した場合にも、セッションが継続されるようにしたかったというのが、前提としてありました。言葉足らずでした。
回答2件
0
ベストアンサー
一般的に、セッション情報を消すタイミングは下記に示すものです。
- ログアウト処理
- セッションタイムアウト
ですので、ご質問に対する回答は「セッションタイムアウトを検知したとき」になります。
一般的な実装としては、セッション内にタイムアウト時刻を保存しておき、当該セッションIDへのアクセスがタイムアウト済みの場合は、セッション破棄済みと同じように扱います。これは「論理削除」と同じ考え方ですね。
上記のタイミングでDBから削除してもよいのですが、それ「だけ」ですと、セッションタイムアウト後に当該セッションIDでアクセスされなかったセッション情報がゴミとして残ってしまいます。この場合の消し方は以下の２つの方法があると思います。
- HTTPリクエストの際に一括して消してしまう（PHPの一般的な実装）
- バッチ処理で定期的にタイムアウト後のセッション情報を削除する（Debian系PHPでの実装）
前者の実装ですと、毎回関係ないセッションの情報まで削除するのは効率が悪いので、PHPの実装では、100リクエストに1回などと指定できるようになっています（session.gc_probabilityと session.gc_divisorの組み合わせで指定）。
ひょっとすると、「いつ破棄するのが一般的でしょうか」の意図は上記かもしれませんね。この辺は一長一短があるわけですので、上記を参考にしつつも、実装上の裁量の余地はかなりあると思います。
投稿2020/11/05 13:36
総合スコア11701
ご丁寧に回答いただきありがとうございます。
すごくわかりやすかったです。
後半に提示していただいた２つの方法が、まさに求めていた内容です。
いただいた情報を元に調べてみて、判断、実装したいと思います。
0
Flaskでログイン機能を実装する場合、Flask-Loginを使うと簡単に実装可能です。
DBとの連携が必要な場合、Flask-SQLAlchemyを使うと簡単に連携可能です。
投稿2020/11/06 00:23
総合スコア2401
ご提案ありがとうございます。
追加で質問させてください。
それらを使うと、ユーザー情報（IDとパスワード）はDBと連携できても、セッションはEC2に保存
される認識ですが、間違っているでしょうか。
※ドキュメントを完全に理解する前に質問しています。申し訳ありません。
背景として、以下のようなことがあります。
ロードバランサーには、同一セッションは同一のEC2に接続するような設定があることを知っています。
しかし、特定のEC2が停止した場合に、そこに接続されていたユーザーのログイン状態を保持することは
できません。
セッションキーはブラウザのCookieに保存されると認識されています。
yahoo1202さんはのセッションは接続単位のセッションのことでしょうか？
先ほどの私のコメントにおける「セッション」はセッションIDのことを指していました。
何をお伝えしたかったかというと、セッションは、発行したセッションIDとユーザー情報を紐づける必要があると思います。ただし、Flaskの機能（Flask-Login Flask-SQLAlchemyなど）を使うと、ロードバランサーの振り分けにより接続されるEC2が変わることで、セッションが継続できないのではないかと思っています。
ロードバランサーを使ったことはありませんが、Flask-Loginのドキュメントを見ると「[Remember Me](https://flask-login.readthedocs.io/en/latest/#remember-me)」が自動的に利用できるので、もしかしたら良い感じに処理してくれるかもしれません。
調べてみます。ありがとうございました。
あなたの回答
tips
プレビュー
