80では2020年2月17日の週以降にデフォルトのSameSite属性が変更されます。Qiitaこの変更が入ると、次のように「決済や認証などで外部サービスを利用し、外部サイトからPOSTで戻ってくるサイト」でユーザーが識別できないエラーが発生します。Qiita)本記事ではRailsアプリケーションでこの問題に対応する方法を紹介します。(disclaimer)この記事のとおりにあなたのRailsアプリケーションを変更して、何らかの不具合やセキュリティ上の問題が発生しても筆者は一切の責任を負いません。技術的な背景と最新の技術情報を十分理解した上で、本記事の内容を適用してください。(適用する必要がない場合は何もしないでください)対応方法rackのバージョンを2.1.0以上に上げます。gemをインストールします。install対応は以上です。Secure属性が追加されます。Secure属性を付けると不具合が発生するブラウザ(参考)に対してはこの属性を付与しません。gemはRails側のCookieを変更するだけで、JavaScript側で設定するCookieには何も変更を加えません。JS内でCookieを設定しているコードがある場合は、何らかの対応が必要になります。(詳細未調査)参考1:動作確認の手順(例)「決済で外部サービスを利用し、外部サイトからPOSTで戻ってくるサイト」を想定した場合の確認手順です。本番環境で試すのではなく、テスト環境(ステージング環境)で試すようにしてください。こちらの手順に従って、Chromeの設定を変更するRailsアプリサイト上で商品を購入し、外部の決済サービスに遷移する2分以上待つ(2分以上待たないとChromeがCookieを送信してしまうため)決済を実行して、自サイトに戻るログイン情報が維持されたまま、正常に決済が完了することを確認する(修正前は何らかの不具合が発生することも事前に確認しておく)参考2:リクエストスペックでテストを書く(例)SameSite=None属性が適切に付与されているかどうかを確認するリクエストスペックの記述例です。gemはSameSite=None属性だけを付与し、Secure属性は付与しません)ログイン処理はDeviseで実現されていることを前提とします。テストコード内の_your_app_sessionは、適宜ご自身のアプリケーション名に合わせて変更してください。本記事を書くにあたって、下記記事を参考にさせてもらいました。ありがとうございました。Ito@jnchitoSIer、社内SEを経て、ソニックガーデンに合流したプログラマ。「プロを目指す人のためのRuby入門」の著者。RSpecによるRailsテスト入門」の翻訳者。upLoginユーザーは見つかりませんでした。