日本語
  • cookie
  • nextjs
  • serverless

Cookie サイズ超過エラーをクッキーを分割して修正する方法

Cookie サイズ超過エラーへの解決策:クッキーを複数の小さなクッキーに分割し、サーバー側で再構築します。この解決策は特に追加のインフラを必要としないサーバーレスプラットフォームで効果的です。

Sijie
Sijie
Developer

概要: Cookie サイズが 4KB のブラウザ制限を超えた場合、クッキーを複数の小さなクッキーに分割し、サーバー側で再構築します。この解決策は特に追加のインフラを必要としないサーバーレスプラットフォームで効果的です。

Logto SDKs におけるクッキーの使用

従来の Web アプリ用のほとんどの Logto SDK では、セキュリティのためにセッションデータを HTTP-only クッキーに保存します。私たちのアプローチは次のとおりです:

SDK がセッションデータを必要とするアクションを実行するとき、SDK は以下を行います:

  • 対称暗号化を使用してデータを暗号化
  • 暗号化された文字列を HTTP-only クッキーに保存
  • HTTPS のみの伝送を保証するためにセキュアフラグを設定

このアプローチは外部ストレージを必要とせず、Vercel などの人気のあるサーバーレスプラットフォームに直接デプロイ可能です。

しかし、複数の組織をサポートする場合、制限に直面します。クッキーサイズが 4KB のブラウザ制限を超えました。なぜなら、以下を保存する必要があるからです:

  • サインインおよびその他のセッションデータ
  • ユーザー認証のための ID トークン
  • リフレッシュトークン
  • 異なるリソースインジケーターを持つアクセストークン
  • 1 つの組織ごとの JWT ペイロードを含む組織トークン(同時に複数の組織が存在する場合、かなり大きくなる可能性があります)

これにより、次のようなエラーが発生しました:

ブラウザは厳格なクッキーサイズ制限を課しており、多くのブラウザは個々のクッキーを 4KB、ドメインごとに合計クッキーサイズを 8KB に制限しています。

外部ストレージの使用については?

Redis やデータベースのような外部ストレージの使用は、追加のインフラを設定する必要があり、SDK ユーザーのコストと複雑さを増加させます。これは、開発者に優しい解決策を提供するという目標に反します。

インメモリストレージは代替手段となる可能性がありますが、インスタンスが一時的でメモリがリクエスト間で共有されないサーバーレス環境ではうまく機能しません。

解決策: クッキーの分割

シンプルな解決策は、大きなクッキーを小さなチャンクに分割することです。この記事では、Next.js を例にアプローチを示します:

1. セッションデータを分割する

2. チャンクを保存する

3. リクエストで再構築する

実装のベストプラクティス

1. チャンクサイズの管理

2. セッション管理のクリーン化

合計クッキーサイズのモニタリング:

結論

クッキーの分割は、実装が簡単で既存のアプリケーションアーキテクチャに最小限の影響を与えるエレガントな解決策を提供します。大きなクッキーを単純に小さなチャンクに分けることで、開発者はブラウザのサイズ制限を克服し、コアセッション管理アプローチを変更せず、外部の依存関係を追加することなく済みます。