すしのへや

thumbnail of tech/bump-supabase-ssr-to-010

@supabase/ssrで​認証まわりを​扱う​ときの​注意

3 min to read

こんにちは、あるいは初めまして。
すしと申します。

Supabase、​便利ですよね!​

Supabaseは、Firebase代替のBaaSであり、DBや認証、ファイルストレージなどの機能を手間なく利用できます。

そんなSupabaseですがSSRやReact Server Components(以下RSC)にもベータながら対応しており、 最近フレームワークを問わない認証ユーティリティである @supabase/ssr がリリースされました。1

このパッケージを使うことでWebフレームワークから簡単に認証機能を扱えて便利なのですが、先日思わぬトラブルに遭遇したので備忘録として書き残しておきます。

結論

必ず@supabase/ssrを0.1.0以上に更新してください。

2024年2月1日以降にインストールした方は特に問題ないはずです。

遭遇したトラブル

Supabase Authを使ってTwitterアカウントでログインする機能を実装している際に、 Twitterのハンドルネームがある程度長い場合のみ、ログインに成功してもセッションが壊れるという不具合が発生しました。

サーバーサイドでデバッグしたところ問題なくセッションが生成できていることが確認できたので、 開発者ツールを確認したところセッションを保持するCookieが正常に書き込まれていないことがわかりました。

原因

このSSRユーティリティを利用する場合、セッション情報は適切な長さのチャンクに分割されてSet-Cookieヘッダにセットされます。

しかし、バージョン0.1.0より前では、この処理はencodeURIComponent()でエンコードする前に行われていました。 そのため、日本語などの文字列が含まれる場合はエンコード後のチャンクが上限である4096バイトを超えることがありました。

ブラウザは上限を超過したCookieを拒否するので、セッション情報が断片的にしか書き込まれず壊れていたわけです。

その後

@supabase/ssr バージョン0.1.0で、事前にURIエンコードした上でチャンクに分割するように修正されました。

これ以降先述したような問題が起きることはなくなりました。

このトラブルを通して、ベータ版のパッケージを利用する際における、アップデートやリリースノートを定期的に確認することの重要性を再認識しました。 DependabotやRenovateといったツールを利用していれば防げた可能性が高いので、きちんと導入しておくべきですね。

それではまたどこかで。

脚注
  1. 以前はフレームワークごとにパッケージが分かれていましたが、今はこちらへ移行することが推奨されています。