应用程序在执行重定向到虚拟目录时丢失身份验证

发布于 2024-08-30 20:00:17 字数 745 浏览 9 评论 0 原文

我有以下设置: http://www.example.com/dir1/http://www.example.com/dir2/

每个虚拟目录都是在 IIS6.0 上配置的作为具有自己的 AppPool 的应用程序。

使用 response.redirect 将经过身份验证的用户从 dir1 重定向到 dir2 时,我丢失了用户的身份验证信息,并且用户被重定向到登录页面。在子域下配置每个应用程序(dir1 和 dir2)时,不会出现此问题,例如: http://dir1.example.comhttp://dir2.example.com

我通过向 machine.config 文件添加机器密钥解决了该问题。

有人可以向我解释为什么它不适用于 http://www.example.com/dir1配置?

I have the following setup:
http://www.example.com/dir1/ and
http://www.example.com/dir2/

Each virtual directory is configured on IIS6.0 as an application with own AppPool.

When redirecting authenticated user from dir1 to dir2 using response.redirect I lose authentication information for the user and the user is being redirected to the login page. This issue was not coming up with each app (dir1 and dir2) were configured under subdomain, ex:
http://dir1.example.com and http://dir2.example.com.

I have resolved the issue by adding a machine key to the machine.config file.

Can someone explain to me why it's not working on a http://www.example.com/dir1 configuration?

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

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

发布评论

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

评论(2

无人问我粥可暖 2024-09-06 20:00:17

我经常以这种方式配置应用程序。有几个地方你可能会误入歧途。

  1. 每个 web.config 必须具有公共 machineKey 部分的精确副本。 EG 生成一个部分并将其粘贴到您想要与其共享 FormsTickets 的所有 web.config 中。

  2. 每个 MembershipProvider(以及角色/配置文件等)元素必须共享相同的 applicationName 属性。默认情况下,这是“/”,因此除非您手动更改它,否则应该不会有问题。

  3. 所有应用程序中的所有提供程序都必须共享一个到公共 aspnetdb 实例的公共连接字符串。

  4. 如果您单独或增量地尝试了这些步骤中的任何一个,则数据库可能处于不一致的状态。确保满足每个要求并从新的数据库开始。

如果您按照这些步骤操作,应该不会有任何问题。这是一个相当常见且直接的用例。

如果您还有其他问题,请告诉我。

I regularly configure applications this way. There are a few places you can go astray.

  1. Each web.config must have an exact duplicate of a common machineKey section. E.G. generate one section and paste it into all web.configs that you want to share FormsTickets with.

  2. Each MembershipProvider (and Roles/Profiles etc) element must share the same applicationName attribute. By default this is '/' so unless you have manually changed it there should be not problem.

  3. All providers in all applications must share a common connection string to a common aspnetdb instance.

  4. If you have tried any of these steps individually or incrementally it is likely that the DB is in an inconsistent state. Ensure that each of these requirements is satisfied and start with a fresh database.

If you follow these steps you should have no problems. This is a fairly common and straight forward use case.

Let me know if you have any more questions.

蓝眼泪 2024-09-06 20:00:17

我不知道 ASP ,但我的猜测是您没有为正在使用的会话 cookie 指定路径,因此路径设置将默认为正在设置 cookie 的路径,/dir1分别是 /dir2

使用子域时,您可能使用 example.com 作为主 Cookie 域,因此两个子域都可以访问它 = 没有问题。

您应该能够通过检查浏览器中的会话 cookie 来找到这一点(例如,在 Firefox 的 Web 开发人员工具栏)。

如果我是正确的,您将需要在某处指定 / 作为会话 cookie 的路径。

我不知道在什么时候进行微调,但也许它会为您指明正确的方向。

I don't know ASP , but my guess would be that you're not specifying a path for the session cookie you're using, so the path setting will default to the path the cookie is being set in, /dir1 and /dir2, respectively.

When using subdomains, you probably used example.com as the main cookie domain, so it was accessible to both subdomains = no problem.

You should be able to find this out by examining the session cookie in your browser (e.g. in the "Cookies" tab in Firefox's Web Developer Toolbar).

If I'm correct, you will need to specify / as the path for the session cookie somewhere.

I don't know at which point to fine-tune that, but maybe it points you into the right direction.

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