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 优点：主要与现有的站点导航 MVC 约定保持一致 缺点：当支持 ID 和 Action 的默认值时，会增加路由的复杂性。

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

提供类似 http://mysite.com/5f1c8bbf-d4f3- 的 URL 41f5-ac5f-48f5644a6d0f/产品/详细信息/5 Pro：简化路由 - 仍然可以按照标准 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 应用程序中处理这种单点登录功能，但我采用了一种稍微不同且简单得多的方法：我创建了一个带有 GatewayController >SignOn 操作将会话令牌和 URL 作为参数。

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

它可能并不完全适用于您的情况，具体取决于您的要求。如果您需要在某处不断检查会话令牌的有效性，那么您可以执行与我相同的操作，然后将会话令牌存储在用户的会话数据中，从而允许您检查每个请求中的令牌。