ASP.NET（Web Forms）の session["sitename"] を使って「modern.com と 180algos.com のどちらのサイト由来か」を、modern.com/freelogin.aspx で判別したい――しかもクエリ文字列やリダイレクト無しで。結論から言うと、別のルートドメイン同士ではブラウザーの制約によりセッション（＝Cookie）をそのまま共有できません。本記事では、なぜ不可能なのかを仕組みから整理し、要件を現実的に満たす代替設計を具体例つきで解説します。
結論：別のルートドメイン同士ではASP.NETのSessionは共有できない
modern.com と 180algos.com のように「ルートドメイン（eTLD+1）が異なる」環境では、ASP.NET のセッション値（session["sitename"]）をブラウザー経由で自動共有することはできません。
理由はシンプルで、ASP.NET のセッションは基本的に「ブラウザーが送ってくるセッションID（Cookie）」を鍵にして復元される仕組みだからです。180algos.com で発行されたセッションID（Cookie）は、modern.com のリクエストでは送られません。したがって modern.com/freelogin.aspx で session["sitename"] を“勝手に引き継いで復元する”ことは不可能です。
なぜ共有できないのか：Sessionは「サーバーにある」けれど鍵はCookie
ASP.NET Sessionの基本構造（InProcでもSQL Serverでも同じ）
ASP.NET の Session は「値そのもの」をサーバー側に保持します。しかし、どのユーザーのセッションを読み出すかは、リクエストに含まれるセッションIDで決まります。典型的には以下の流れです。
| 要素 | 役割 | どこにあるか | 別ドメイン共有の可否 |
|---|---|---|---|
Sessionの中身（例：session["sitename"]） | 状態（どのサイト由来か、ログイン状態など） | サーバー側（メモリ／StateServer／SQL Server等） | 共有ストアに置けば“保存先”は共通化できるが、後述の鍵問題が残る |
セッションID（例：ASP.NET_SessionId） | Sessionを引くためのキー | ブラウザーのCookie | 別ルートドメイン間では送られないため不可 |
ここで重要なのは、Session を SQL Server や Redis 的な共有ストアに移しても「セッションIDを運ぶのはCookie」という点は変わらないことです。保存先を共有化しても、modern.com が受け取るべきセッションIDがブラウザーから届かなければ、結局どのレコードを引けばいいか分かりません。
Cookieは“同一オリジン”の信頼境界で分離される
ブラウザーは、Cookie を「どのドメインに送るか」を厳密に制御します。基本は次のルールです。
- Cookieは原則として発行したドメイン（ホスト）にしか送られない
- Cookie の
Domain属性で “親ドメイン” まで共有範囲を広げられる（例：.example.com） - ただし 無関係な別ルートドメイン（例：
modern.comと180algos.com）をまたいで共有することはできない
つまり、180algos.com が modern.com 宛てのCookieを勝手にセットすることも、modern.com が 180algos.com のCookieを読むこともできません。これが「別ドメインでセッション共有ができない」本質的な理由です。
例外：同一ルートドメイン配下のサブドメインなら共有できる
要件を満たす方法として最も根本的で強いのは、そもそも別ドメインをやめることです。例えば次のように “同一ルートドメイン配下のサブドメイン” に寄せると、Cookie の共有が現実的になります。
| 構成 | 例 | Cookieの共有 | コメント |
|---|---|---|---|
| 同一ルートドメイン配下（サブドメイン） | sv1.test.com と sv2.test.com | 可能（Domain=.test.com） | Sessionや認証Cookieを“同じ親ドメイン”で扱える |
| 別ルートドメイン | modern.com と 180algos.com | 不可 | ブラウザーがCookieを送らないため、Session復元ができない |
「どうしてもクエリ文字列もリダイレクトも無しで自然に判別したい」という要件に近づけるなら、技術的にはドメイン統一（サブドメイン化／同一ドメイン配下に統合）が最も現実的です。逆に言うと、ドメインが別のままでは“渡す工程ゼロ”は成立しません。
「クエリ文字列やリダイレクト無し」が難しい理由
今回の相談の核心は「freelogin.aspx は modern.com 側にしか存在しないのに、どのサイトから来たかを session["sitename"] で自動判定したい」という点です。しかし、HTTP は基本的にステートレスで、アクセスしてきた 1 回のリクエストだけを見ても「出所（どのサイト由来か）」は分かりません。
直打ちアクセスは“文脈が無い”
https://modern.com/freelogin.aspx をユーザーがブックマークや直打ちで開いた場合、サーバー側から見ると「ただの modern.com へのアクセス」です。そこに 180algos.com の情報は乗りません。
Refererは万能ではない
「Referer（リファラ）を見れば？」と思われがちですが、Referer は以下の理由で期待通りに来ないことが普通にあります。
- ブラウザー／拡張機能／セキュリティ設定で送られないことがある
https → httpの遷移、プライバシー保護ポリシーで落ちるケースがある- 意図せず別ページを経由すると“どこから来たか”が変わってしまう
Referer は補助情報にはなっても、「システム要件として確実に判別」する根拠にはしづらいのが実情です。
現実的な代替案：どれも“何らかの受け渡し”は必要
別ルートドメインを維持したまま要件を満たすには、残念ながら 何らかの形で情報（またはトークン）を受け渡す工程が必要です。ここでは、実務で採用されやすい順に整理します。
代替案の比較表（実装コスト・安全性・ユーザー体験）
| 案 | 概要 | クエリ文字列不要 | リダイレクト無し | 安全性 | 実装コスト | 向いているケース |
|---|---|---|---|---|---|---|
| ドメイン統一（サブドメイン化） | 同一ルートドメイン配下に再編しCookie共有 | ○ | ○ | 高 | 中〜高 | 運用を含めて構造を整理できる／長期運用 |
| SSO（OAuth/OIDC/SAML等） | 共通の認証基盤でユーザーを特定し状態を引く | ○（実装次第） | △（多くは認証フローで発生） | 高 | 中〜高 | 複数サイトをまたぐログインが必要／将来拡張 |
| POSTで一時トークンを渡す | フォームPOSTで短命トークンを送る（URLに出さない） | ○ | △（画面遷移は発生） | 中〜高（設計次第） | 中 | 「URLに出したくない」要件が強い／短期実装 |
| 共有ストア＋ユーザーIDで引く | 共通DBに状態を書き、modern.com 側でユーザーIDから復元 | ○ | ○ | 中 | 中 | 両サイトで同じ会員IDを持つ／既に共通DBがある |
| ユーザーに選択させる | 「どちらのサイトですか？」を選択してもらう | ○ | ○ | 中 | 低 | 完全自動判定が不要／最小工数で止血 |
おすすめの考え方：Session共有ではなく「ユーザー特定」と「状態の復元」に分解する
今回の要件は「セッションを共有したい」という形で語られていますが、実際に欲しいのは以下の 2 点に分解できます。
- 誰がアクセスしてきたか（ユーザー特定）
- そのユーザーが “どのサイト文脈” で来たか（状態復元）
別ドメイン間で Session をそのまま共有しようとすると詰みますが、上の分解に沿って設計すると解けることが多いです。
代替案：SSO（共通認証）に寄せると長期的に強い
複数ドメインをまたいだログイン体験を安定させたいなら、SSO（Single Sign-On） が王道です。OAuth 2.0 / OpenID Connect（OIDC）や SAML などを使い、共通の認証基盤（IdP）でユーザーを認証します。
SSOを使うと何が嬉しいか
- ドメインが分かれていても「同一ユーザー」であることをサーバー側で確実に判断できる
session["sitename"]のような“文脈情報”をサーバー側のルールで復元できる- ログイン、二要素認証、パスワードポリシー、監査ログなどを共通化できる
注意点：認証フローでは画面遷移（リダイレクト）が一般に発生する
OIDC などの標準的フローは、セキュリティ上の理由もあり「認証画面への遷移 → コールバック」などの画面遷移が入ります。どうしても“リダイレクト無し”にこだわる場合、SSOは要件と衝突しやすいです。ただし、実運用では「ユーザーの体感が自然ならOK」と要件を調整して採用されることが多いです。
代替案：URLに出したくないなら「POSTで一時トークン」を渡す
「クエリ文字列（URL）に sitename を出したくない」「リダイレクトで値を付けたくない」という要望が強い場合、実務で取りやすい折衷案がフォームPOSTで一時トークンを渡す方式です。
ポイントは、渡すのは sitename そのものではなく、短命・一回限りのランダムトークンにすることです。これなら漏えい時の影響を最小化できます。
フロー例（180algos.com → modern.com/freelogin.aspx）
180algos.com側で「site=180algos」を表すワンタイムトークンを生成（例：128bit以上の乱数）- トークンとサイト名、期限（例：60秒）を共有ストア（DB/Redis等）に保存
- ブラウザーに対して、
modern.com/freelogin.aspx宛に フォームPOST でトークン送信（自動submit） freelogin.aspx側でトークンを検証し、対応するサイト名を取得してsession["sitename"]を確定- トークンは即時無効化（再利用不可）
画面遷移の実装例（クエリ文字列を使わずPOSTで渡す）
以下は「URLに値を載せず、POSTでだけ渡す」最低限のイメージです。実際は HTTPS 前提・CSRF/期限/一回性などの対策を必ず入れてください。
<form id="handoff" method="post" action="https://modern.com/freelogin.aspx">
<input type="hidden" name="token" value="RANDOM_ONE_TIME_TOKEN" />
</form>
<script>
document.getElementById('handoff').submit();
</script>
freelogin.aspx 側（C#）は概念的には次のようになります。
// freelogin.aspx.cs（概念例）
protected void Page_Load(object sender, EventArgs e)
{
var token = Request.Form["token"];
if (string.IsNullOrEmpty(token))
{
// 直打ちやブックマーク等。出所が不明なので安全側に倒す
// 例：選択画面へ / エラー表示 / デフォルトサイトへ
return;
}
// 共有ストアで token を検証（期限・未使用・発行元など）
// 例：var siteName = TokenStore.VerifyAndConsume(token);
// siteName が "modern" or "180algos" など
Session["sitename"] = siteName;
}
この方式のメリットと現実的な落としどころ
- URLに値を出さない（ログ、履歴、共有リンク、スクショ等に残りにくい）
- 「渡す値」をワンタイムトークンにすることで、改ざん・なりすまし耐性を上げられる
- ただし、画面遷移そのもの（別ドメインに移動する行為）は必ず発生するため、厳密な意味で「リダイレクト無し」を完全維持することはできない
要件を現実に落とすなら、「クエリ文字列は使わない（POSTで渡す）」や「ユーザー体験として目立つリダイレクトは避ける（自動遷移）」など、言葉の定義を調整するのが成功パターンです。
代替案：共有ストア＋ユーザーIDで引く（ただし“ユーザー特定”が必須）
すでに会員DBが共通で、両ドメインが同じユーザーID（会員ID、メールアドレス、外部Idのサブジェクトなど）でユーザーを特定できるなら、「サイト文脈」をDBに保存しておき、modern.com 側で引き直す設計も有効です。
典型パターン
180algos.com側でユーザーがログインしたら、DBに「最後に利用したサイト=180algos」を保存modern.com/freelogin.aspxに来たら、modern側で認証済みのユーザーIDからDBを引き、サイト文脈を復元
ここでのボトルネックは明確で、modern.com 側が「このアクセスは誰なのか」を分からないと引けません。つまり、結局どこかで認証（ユーザー特定）が要るという点は避けられません。
どうしても“受け渡し無し”にこだわるなら、要件側を調整するしかない
設計上の現実として、別ドメイン間で「何も渡さずに出所を判別する」ことはできません。ならば、何を調整すれば実現可能になるのかを整理すると、議論が前に進みます。
| こだわりポイント | そのままだと起きる問題 | 現実的な落としどころ |
|---|---|---|
| クエリ文字列を使いたくない | URLに情報が出せず、値の受け渡し手段が限られる | POSTでワンタイムトークンを渡す／URLに載せるのはランダム値だけにする |
| リダイレクト無し | 別ドメインへ移動するには何らかの遷移が必要 | “目立つリダイレクト”を避ける（自動遷移、同一画面風にする）／SSOの遷移を最小化 |
| 自動判定したい | 直打ちやブックマークでは出所情報が無い | 直打ちは例外として選択UIを出す／デフォルトサイトに寄せる／招待リンク等の“入口”を統制する |
| 既存構造は変えたくない | 最適解（ドメイン統一）が取りにくい | 短期はPOSTトークン、長期でSSO/ドメイン統合のロードマップを作る |
よくある勘違い：ここを押さえると設計ミスが減る
「SessionをSQL Serverにしたら別ドメインでも共有できる？」
保存先をSQL Serverにしても、リクエストに載ってくるセッションID（Cookie）が別ドメインへは運ばれません。保存先の共有化は“必要条件になり得る”だけで、“十分条件”ではありません。
「180algos.com から modern.com 用のCookieを発行すれば？」
ブラウザーはドメイン不一致のCookieを受け付けません。たとえレスポンスヘッダーで Set-Cookie を工夫しても、180algos.com のレスポンスで modern.com に紐づくCookieは基本的にセットできません。
「JavaScriptでCookieを移植すれば？」
そもそも JavaScript は同一オリジン制約により他ドメインのCookieにアクセスできません。移植以前に読み取れません。
「CORSを設定すればいける？」
CORSは「別オリジンへXHR/fetchでアクセスする制御」であり、Cookieの“共有”を可能にする仕組みではありません。今回の問題の本丸（ブラウザーがCookieを送らない）には効きません。
実務でのおすすめ：短期と長期で分けて設計する
現場では「今すぐ動かしたい」と「将来も破綻しない」が同時に求められます。おすすめの組み立て方は次の通りです。
短期（最小の改修で要件に近づける）
- 入口（
180algos.comなど）からmodern.com/freelogin.aspxへは POSTでワンタイムトークン freelogin.aspx直打ちは例外扱い（選択UI、デフォルト動作、エラーのいずれかを明確化）- トークンは「短命」「一回限り」「推測不能」「可能ならユーザーに紐づけ」
長期（運用とセキュリティを安定させる）
- SSO（OIDC/SAML）でユーザー特定を共通化し、サイト文脈はサーバー側で復元
- 可能ならドメイン統一（サブドメイン化、あるいは同一ドメイン配下に寄せる）を検討
- ログイン、権限、監査、セッション管理を一本化し、サイト追加にも耐える
まとめ：別ドメイン間でSession共有は不可。必要なのは“設計の切り替え”
modern.com と 180algos.com のような別ルートドメイン間では、ASP.NET のセッション値（session["sitename"]）をそのまま共有することはできません。Session の本体がサーバー側にあっても、復元の鍵となるセッションID（Cookie）がドメイン境界を越えられないからです。
要件を満たす現実的な道は、(1) ドメイン統一（サブドメイン化）でCookie共有を可能にする、(2) SSOでユーザー特定を共通化して状態を復元する、(3) URLに出さずにPOSTでワンタイムトークンを渡す――といった「設計変更」にあります。特に freelogin.aspx を直打ちできる運用なら、出所判定は原理的に不可能なため、直打ち時の挙動（選択UI/デフォルト/エラー）を仕様として決めることが、トラブルを減らす最短ルートになります。
コメント