在 ASP.NET IIS7 中存储子域组的会话 cookie

发布于 2024-10-10 06:46:24 字数 859 浏览 2 评论 0原文

我有一个运行 ASP.NET 的应用程序。我有不同的域和不同的子域。我希望域与其子域共享会话。

例如,以下域访问此应用程序:
www.example1.com
print.example1.com
www.example2.com
print.example2.com

如果用户访问 www.example1.com 和 print.example1.com,我希望它使用同一个会话。如果用户要访问 www.example2.com 和 print.example2.com,我希望它使用与 *.example1.com 不同的会话。

我用来处理它的方法是对 page_load 进行修改,该修改在 IIS6 中完美运行:
Response.Cookies["ASP.NET_SessionId"].Value = Session.SessionID;
Response.Cookies["ASP.NET_SessionId"].Domain = SiteUtility.GetCookieDomain();
(SiteUtility.GetCookieDomain 将返回 .example1.com 或 .example2.com,具体取决于请求的 url)

不幸的是,这似乎不再适用于 iis7。用户访问的每个子域/域都会获得一个新的会话 cookie。

然后我找到了 web.config 条目:
'

这非常适合在 example1.com 子域之间共享会话 cookie。不幸的是,这完全搞乱了 *.example2.com 的会话状态。

关于如何解决这个问题有什么想法吗?

I have an application running ASP.NET. I have different domains and different sub-domains. I want the domains to share session with their sub domains.

For Example, the following domains access this application:
www.example1.com
print.example1.com
www.example2.com
print.example2.com

If a user goes to www.example1.com and print.example1.com, I want it to use the same session. If the user were to go to www.example2.com and print.example2.com, I would want it to use a different session than the *.example1.com.

The way I used to handle it was a hack in page_load that works perfectly in IIS6:
Response.Cookies["ASP.NET_SessionId"].Value = Session.SessionID;
Response.Cookies["ASP.NET_SessionId"].Domain = SiteUtility.GetCookieDomain();
(SiteUtility.GetCookieDomain would return .example1.com or .example2.com depending on the url of the request)

Unfortunately, this no longer seems to work for iis7. Each subdomain/domain a user goes to, the user gets a new session cookie.

I then found the web.config entry:
'<httpCookies domain=".example1.com" />.

This works great for sharing session cookie between example1.com subdomains. Unfortunately, this completely screws up session state for *.example2.com.

Any ideas on how I can solve this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

明媚殇 2024-10-17 06:46:24

您是否尝试过创建一个 HttpModule 来拦截 EndRequest 事件,迭代 Response.Cookies 集合,查找会话cooke并更改其在实际将其发送到客户端之前的 Domain 属性。

编辑:

Kevin 最后确定其中一个子域在 ie8 中处于受信任状态,而另一个则不是。当两者都处于受信任状态(并且可能都处于不受信任状态)时,它就可以工作。我确实在这个问题上花了最多的时间,所以凯文想把答案归功于我。

Have you tried creating a HttpModule that intercepts the EndRequest-event, iterates over the Response.Cookies collection, finds the session-cooke and changes its Domain property before actually sending it to the client.

Edit:

Kevin at the end determined that one of the subdomains was in a trusted state in ie8 while the other was not. When both are in a trusted state (and presumambly both in an untrusted state) it works. I did spent the most time on this, so Kevin want to give me the credit for the answer.

无力看清 2024-10-17 06:46:24

不要使用 SiteUtility.GetCookieDomain(),而是尝试使用:

var domainSansTLD = Request.Url.Host.Replace(".com", "");
var secondLevelDomain = domainSansTLD.Substring(domainSansTLD.LastIndexOf('.'));
var cookieDomain = secondLevelDomain + ".com";

rather than using SiteUtility.GetCookieDomain(), try using:

var domainSansTLD = Request.Url.Host.Replace(".com", "");
var secondLevelDomain = domainSansTLD.Substring(domainSansTLD.LastIndexOf('.'));
var cookieDomain = secondLevelDomain + ".com";
无风消散 2024-10-17 06:46:24

第一种方法,

将会话作为文件存储在两个服务器都可以访问的位置(这对于虚拟服务器或共享文件夹很有用)。这种方法有点不可靠,并且共享文件夹和滞后从而导致问题。

好吧,我本来打算写一些其他方法,但我确信它们会被发布,因为他们比我对 ASP.NET 有更多的了解,但是,我确实有个人偏好,我认为这将是一个不错的选择。

这个选项是一个内存缓存服务器。本质上,它是一个使用 RAM 运行的数据库,您将所有会话都指向它(tcp://mem.domain.com:1234 ...抱歉,我不记得通常的端口了)。

我希望我能帮上忙,

乔恩

First way,

Store session as file in a location that both servers can access (this is good for virtual servers or shared folders). This method is a bit unreliable and shared folders and lag thus causing problems.

Okay, I was going to write a couple of other methods but I'm sure they'll be posted as they have more knowledge with asp.net than I, however, I do have a personal preference that I think would be a good option.

This option would be a memcache server. Essentially it's a database that runs off RAM and you point all of your sessions to it (tcp://mem.domain.com:1234 ... sorry I can't remember the usual port off the top of my head).

I hope I was of some help,

Jon

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文