ローカルでLaravelアプリをDocker環境に移行し、AWSのEC2へそのままデプロイしました。
EC2上でdocker-compose up -dをして立ち上げ、サイトにアクセスしたら、
表示はされるのですが、ログインフォームや登録フォームを送信したら、こんな状態に。
かなり対処に苦労したので、記録しておきます。
環境
Mac OS Catalina 10.15.4
PHP: 7.2.24
Laravel: 5.5.48
Docker: 19.3.６
Docker-compose: 1.16.1
AWS: AMI: Amazon Linux2
EC2: t2.micro（無料枠のやつ）
どういうことか
画像の文字の意味的には「このページは期限切れだから更新してみて」的な感じ。
これが出る時は多くがCSRFトークンの期限切れだそうです。
え？セッション切れるほど放置してないけど...
試してみたこと
セッションの有効時間を確認してみる。
Laravelの.envファイル内に、
SESSION_LIFETIME=120
があると思いますが、これがセッション有効期限です。（分）
session.phpにも記述があるそうですが、.envファイルの記述が優先されるみたいです。
しかし私の場合はそんなに放置してない。
sshでログインしてEC2のタイムゾーンを確認してみる。
[ec2-user@ ... ]$ date
2020年 6月 6日 土曜日 xx:xx:xx UTC
なるほど。UTCになってますね。
つまり時間差が出来てしまったからセッション切れたようになってしまったのか？
こちらの記事を参考にタイムゾーンを変更します。
[ec2-user@ ... ]$ date
2020年 6月 6日 土曜日 xx:xx:xx JST
JSTになりました。
再度動作確認。
...変わらない。
コンテナ内でもタイムゾーン確認してみる。
$ docker exec -it [コンテナ名] bash
/var/www# date
Sat Jun 6 xx:xx:xx UTC 2020
おっと、UTCになってますね。こっちが原因なのか？
こちらの記事
を参考にさせて頂き、docker-compose.yml内へタイムゾーンを力技で捻じ込む。
...
environment:
TZ: 'Asia/Tokyo'
...
再度確認してみます。
/var/www# date
Sat Jun 6 xx:xx:xx JST 2020
変わりましたね。これで大丈夫か...？
ダメでした。
CSRFトークンの記述漏れか確認する。
どうもこれがパターンとしては多いそうです。この記述漏れがフォーム内に無いか確認する。
Laravel 5.5 以前
{{ csrf_field() }}
Laravel 5.6 から
@csrf
あります。ちゃんと書いてます。自分えらい。
でもこれが原因でもない。
セッションドライバをcookieにしてみる
“The page has expired due to inactivity” - Laravel 5.5
stackoverflowにこんな記事がありました。
ここのコメントによると、
「セッションドライバをファイルにしていると、storage_pathのパーミションでこの表示が出る時がある」
らしいです。
セッションドライバとは、
セッションドライバ(driver)はリクエスト毎のセッションデータをどこに保存するかを決めます。
だそうです。
.env
SESSION_DRIVER=file
じゃパーミッション変更したらええやん、って思いましたが、別の記事で結構言われていたので、まぁ確かにと思いつつ、公式の日本語訳ページを参考にしながら、
SESSION_DRIVER=cookie
に変更してみました。
そうしたらやっと動いてくれました。
でもローカルではエラー出なかったのになぜ？
AWSに移行すると変更されちゃうのか？
理由をご存知の方いましたらぜひ教えていただけたら幸いです。
参考記事
【Linux】タイムゾーン(Timezone)の変更
Dockerコンテナのタイムゾーン変更方法
“The page has expired due to inactivity” - Laravel 5.5
Laravel 5.3 - TokenMismatchException in VerifyCsrfToken.php line 68:
Laravel 5.5 HTTPセッション
非常に勉強になりました。ありがとうございました。