認証と API 操作に中央ドメインを使用するマルチドメイン プラットフォームがあります。
API & 認証 + アカウント管理
https://example.com
読み取り専用 + ウィジェット アクション
http://example.comhttp://example.nethttp://example.org
このタイプのセットアップに関する StackOverflow の質問のほとんど (すべてではないにしても) を読みましたが、この懸念についての洞察を見つけることができませんでした。(これに関するほとんどの Q&A は、関連する一般原則に関するものであり、詳細についてはほとんど触れていません)。
と他のドメイン名のPorthole.js間で API 呼び出しをプッシュするために (javascript iframe プロキシ ライブラリ) を使用しています。https://example.comすべてが完璧に機能します。
「ログイン状態」に頭を悩ませ、JavaScriptをカスタマイズするためにユーザーデータを永続化しようとしています。
StackOverflow 自体のようなサイトがどのようにモデル化されているかを見て、私が最初に考えたのは次のことでした。
- ログイン ステータス + カスタマイズ データ (ユーザー名、写真など) + cookie データを localStorage に
https://example.com10 分間、またはログアウトするまでキャッシュします。10 分後、キャッシュはサーバーの API にヒットして更新されます。 - ネットワーク サイトへの最初のヒット時に、リモートの localStorage をクエリします。ログインしている場合は、ログイン ステータス、カスタマイズ データ、および http (https ではない) Cookie ID をプロキシ バックします。このデータは、10 分間またはログアウトするまで「最新」と見なされます。
- からの Cookie
http://example.comが要求側ドメインに複製され、そのセッションが置き換えられます。これにより、ドメイン全体で単一の Cookie / ID を使用できます。
追跡と「プレビュー」アクセスにのみ使用されるにもかかわらず、私はその最後のステップである http Cookie のクローン作成について最も心配しています。しかし、このシステム全体はブラウザのセキュリティ モデルに依存しており、何かが欠けている可能性があります。AuthTicket モデルを使用したかのように、洗練された「安全な」メカニズムのようです (ユーザーはhttps://example.com/auth-request?destination=http://example.net/auth-responseにアクセスし、http://example.net/auth-response?nonce=VERYBIGNUMBERにリダイレクトされるか、iframe 内で透過的な oAuth リクエストが行われます。
私が見逃した明らかな/明白なセキュリティ上の懸念に誰かが光を当てることができますか、またはこれは代替案と同じくらい安全だと思われますか?