昔のCSRFの実装方法を今考え直してみた
なぜ、セッションクッキーの中に時間を入れてたのか？
CookieのMaxAgeでコントロールすればいいだけなのに
あ！！
CookieのMaxAgeはブラウザ側で書き換えが可能だから？
セッションの有効期限を伸ばせるとずっとログイン状態に出来てしまうから？
IDを暗号化したのをクッキーに入れてるだけなので、一度セッション情報がわかると、ずっと同じクッキーの使い回しが可能だから
元々は投稿側もoauth認証でログインさせてたからセッションが永久に保つ事に抵抗があったからこういう実装になったかと思う
たかが、クイズのアプリなのでセッションが永久で問題ないけども
本当にセキュアにしたければ、やはり、セッション情報をredisとかのサーバー側に保存が一般的でそれ以上の事はないかと
かといって、クイズアプリのセッションのセキュリティレベルを上げたいがためにredisを入れるのはサーバーリソース的に勿体無い。
という事で、クッキー x 暗号化で仮セッションを作るのがベストかと当時考えてたと思います。
CSRFを外した理由
エラーログをみてるとCSRFエラーが連発していた
理由がわからなかったので、とりあえずCSRFを外した
今わかった事はCSRFは各ユーザーのセッション毎に保存しないといけない
出ないと同時にアクセスした時にCSRFが違うとエラーになってしまう
Aがページにアクセス、Bがページにアクセス
AがPOST ＞＞ CSRFはBのアクセスを保持しているのでエラー
こういう時フレームワークとかはセッションで保存する機能を提供しているけど、クイズアプリなので、その必要もないのかも
CSRFをユーザー毎のセッションに保存しないといけないとなるとページにアクセスしたすべてのユーザーにセッションIDを振らないといけない。。。
そうなるとシーケンスのカウントアップが極端に増えてしまう。。
一時的なセッションの発行が良さげ。
という事と考えてたけども
今、ソースコードを見たらそうなってはなくて各々のクッキー毎にCSRFを発行しているので上での論理は通用しなくなっている
うーん。時間を2時間から4時間ぐらいにしようかな。。
昔書いたコードを見て思い出しながら実装内容を確認すると古い写真を見てる感覚が少ししたかも
登録日：
更新日：