http/httpsが混在する環境でのセキュアCookieの取り扱い
WEBサービスをhttpsで提供するのが当たり前になりました。 イートスマートのWEBサービスもhttpsへの移行を完了しています。
そうした中で、社内向けツールで不具合が報告されました。 社内向けツールなので、スタッフが社内からのみ利用します。このため、httpsへの移行を行うことなく利用していました。 ドメインは社内向けツールが共通で利用するもの（仮にeatsmart.officeとします）となっていて、以下のようなURLでアクセスして利用しています。
http://eatsmart.office/backend/
不具合の内容から、どうやらセッションが維持出来ていないことが原因のようです。 アプリケーションはTomcatで稼働しています。セッションは HttpServletRequest#getSession で参照します。 セッションIDをログに出力して確認したところ、セッションは正しく維持されており、問題なく操作が行なえます。 再現することが出来なかったこともあり、報告のあったスタッフには一旦Chromeのシークレットウィンドウで作業をしてもらうことで対応しました。
その後、社内ツールの機能追加を行い動作を確認していたところ、報告のあった不具合が発生しました。 アクセスするたびにセッションIDが新しくなります。Tomcatでセッションの管理にはCookieを利用しています。 Cookieの内容を確認するためChromeでJSESSIONIDを調べたところ、セッションIDが書き込まれていませんでした。 不思議に思い、何度もリロードしたり、明示的にJSESSIONIDを書き出しても、Cookieには書き込まれません。
次にレスポンスヘッダに問題が無いかChromeのNetworkタブを見たところ、以下のような警告が表示されていました
既にセキュアCookieが存在するため上書き出来ないというエラーです。 上にも書いたように社内向けツールはhttpsへ移行していないためセキュアCookieを利用していません。 そこで調査をしたところ、もぐナビの社内向け環境が同一ドメインで稼働していました。
もぐナビはhttpsへ移行しているため、もぐナビの社内向け環境もhttpsとなっており、かつセキュアCookieを利用していました。 このため、先にもぐナビの社内向け環境にアクセスしてセキュアCookieが書き込まれてしまうと、社内向けツールでCookieに書き込めない状態になっていました。
セキュアCookieのこのような挙動は理解していましたが、社内からのみ利用する環境だったこともあり、発見するまで時間がかかってしました。 http/httpsが混在する環境かつどちらでも書き込み・参照が必要なものにかんしては、アプリケーションサーバがセキュアCookieを書き出さないか確認が必要です。
