Auth.js

The Setup Saru has 4 portals: System, Provider, Reseller, Consumer. Each runs on a different subdomain, but they share one Keycloak realm. system.saru.local (port 3001) → Keycloak provider.saru.local (port 3002) → (single realm, reseller.saru.local (port 3003) → 4 clients) consumer.saru.local (port 3004) → Basic Keycloak + Auth.js integration is well-documented in existing tutorials. This article covers the problems those tutorials don’t mention. Pitfall 1: Cookie Collision Across Subdomains The Problem We wanted cross-subdomain session sharing for potential future use, so we set: ...

構成 Saruには4つのポータルがあります：System、Provider、Reseller、Consumer。それぞれ異なるサブドメインで動作しますが、1つのKeycloakレルムを共有しています。 system.saru.local (port 3001) → Keycloak provider.saru.local (port 3002) → (単一レルム、 reseller.saru.local (port 3003) → 4クライアント) consumer.saru.local (port 3004) → 基本的なKeycloak + Auth.js統合については既存のチュートリアルで十分にカバーされています。この記事では、それらのチュートリアルでは触れられない問題を扱います。 落とし穴1: サブドメイン間のCookie競合 問題 将来的な利用を見越して、サブドメイン間でセッションを共有したいと考え、以下のように設定しました： 1 2 3 4 5 6 7 cookies: { sessionToken: { options: { domain: '.saru.local', // サブドメイン間で共有 }, }, } 結果：System PortalにログインするとProvider Portalでも同じセッションが表示されました。しかしそれは間違ったユーザーコンテキストでした。System管理者のトークンがProvider Portalで使用されていたのです。 ...