为什么 Asp.net Web 项目的 url 中有垃圾值？
我尝试过在谷歌上搜索并搜索这个问题 - 但收效甚微 - 主要是因为我不确定我的搜索是否正确。
我正在开发一个 ASP.Net Web 应用程序项目（不是网站），使用 Visual Studio 2008、C# 和 Cassini 进行测试。
但是，每次运行该网站时，我都会得到一个 URL，例如：
http://localhost:8671/(S(saifdk55xyhalrqbstrtrdiw))/SubjectClassTeacher/Default.aspx
即使我修改 URL 并尝试访问：
http://localhost:8671/SubjectClassTeacher/Default.aspx
我也会被重定向回此 URL。
中心的垃圾值： (S(saifdk55xyhalrqbstrtrdiw)) 每隔几次编译就会不断变化，我不知道为什么它会被注入或如何禁用它。
有人能阐明这个问题吗？ 首先，我想知道为什么会发生这种情况以及如何禁用它。
因为当我在 IIS 上部署网站时也会发生这种情况。 任何帮助表示赞赏。
谢谢。
I have tried googling and searching for this issue on SO - but have had little success - primarily because I am not sure whether I am searching right.
I am working on an ASP.Net Web Application Project (not website) using Visual Studio 2008, C# and Cassini for testing.
However, everytime I run the site, I get a URL such as:
http://localhost:8671/(S(saifdk55xyhalrqbstrtrdiw))/SubjectClassTeacher/Default.aspx
Even if I modify the URL and try to go to:
http://localhost:8671/SubjectClassTeacher/Default.aspx
I am redirected back to this URL.
The garbage value in the center: (S(saifdk55xyhalrqbstrtrdiw)) keeps changing every few times I compile and I have no idea why it gets injected or how to disable it.
Could anyone throw any light on this issue?
Primarily, I would like to know why this happens and how do I disable this.
Because this happens when I deploy the website on IIS as well.
Any help is appreciated.
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是 ASP.NET* 中的一项巧妙功能，称为无 Cookie 会话。它的工作原理是将您的会话 ID 注入每个 URL，因此 ASP.NET 可以区分访问页面的用户 A 和访问同一页面的用户 B。通常这是通过 cookies 来完成的，但这种方法消除了对最终用户启用它们的依赖。
来自 MSDN：
*这个概念并不是 ASP.NET 独有的，但它已融入 ASP.NET 中，并且 - 正如您所发现的 - 可以通过以下方式打开开发人员无需付出特别的努力。
This is a clever feature in ASP.NET* called cookieless sessions. It works by injecting your session ID into every URL, so ASP.NET can tell the difference between user A who visits a page, and user B who visits the same page. Normally this is accomplished with cookies, but this approach removes the dependency on the end-user having them enabled.
From MSDN:
*The concept is not exclusive to ASP.NET, but it is baked into ASP.NET and - as you've discovered - can be turned on with no particular effort on the part of the developer.