ASP.NET MVC 建议使用会话令牌路由 URL

Question

我正在尝试实现一个与另一个站点交互的小型 ASP.NET MVC 站点。简而言之，通过 URL 中的令牌管理主站点和附属站点之间的会话。我可以指定 url 格式，但我不能删除会话令牌作为 URL 的一部分提交的要求。

我正在研究如何设置路由，我对此有一些想法。我无法决定哪个是最好的，或者是否有更好的方法来做到这一点。我的主要思路：

routes.MapRoute("Main", "{controller}/{action}/{id}/{token}");

给出像http://mysite.com/Products/Detail/5/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f这样的URL 优点：主要与现有的 MVC 约定进行站点导航 缺点：在支持 ID 和 Action 的默认值时增加了路由的复杂性。

routes.MapRoute("Main", "{token}/{controller}/{action}/{id}/");

给出像http://mysite.com/5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f/Products/Detail/5这样的URL 优点：简化路由 - 仍然可以按照标准 MVC 约定应用操作/ID 默认值 缺点：非常“不像网络”的 URL。需要正则表达式来验证第一个变量是有效的 GUID/令牌，然后再转到表中的下一个路由。

想到的另一种可能性，通过会话，例如：

http://mysite.com/Home/Index?session=5f1c8bbf-d4f3-41f5-ac5f-48f5644a6d0f

与此相关的问题是我有一个从 Controller 派生的基类，所有其他安全页面都在通过该基类。 SecureController 类覆盖 Execute() 并检查从 URL 获取的令牌的有效性。两种方法（GET 和路由）似乎很容易在控制器 Execute() 函数中获取令牌，但是 GET 方法感觉有点俗气，而路由方法感觉就像是，由于缺乏更好的解释，打破了MVC 路由设计的优雅。

有没有其他人遇到过类似的问题并有什么特别的成功或困难可以分享？

Answer 1

看来不管你怎么做，你的 URL 都会被那个令牌弄得一团糟。

我也不得不在 ASP.NET MVC 应用程序中处理这种单点登录功能，但我采用了一种稍微不同且更简单的方法：我创建了一个带有 SignOn 操作的 GatewayController以会话令牌和 URL 作为参数。

然后这个SignOn 操作只会检查会话令牌的有效性，然后将用户登录到我的站点，重定向到提供的 URL。从那时起，不再需要会话令牌，因为从那时起身份验证将基于 cookie。

根据您的要求，它可能并不完全适用于您的情况。如果您需要在某处不断检查会话令牌的有效性，那么您可以像我一样做同样的事情，然后将会话令牌存储在用户的会话数据中，允许您检查每个请求中的令牌。