单一身份验证网址？为什么不在任何 URL 上进行身份验证？答案

【问题标题】：Single auth URL? Why not authenticate on ANY URL?单一身份验证网址？为什么不在任何 URL 上进行身份验证？
【发布时间】：2011-01-23 11:21:01
【问题描述】：

为什么你好 SOers。我今天的问题是关于身份验证端点及其周围的架构。

我遇到的大多数 Web 框架和应用程序似乎都有一个 URL 或端点来处理“身份验证” - 例如。处理用户名和密码等身份验证令牌，并对其进行处理。

在我看来，这会导致很多后续工作，例如，如果您点击需要身份验证的 URL，系统需要将该 URL 传递给身份验证端点，以便在身份验证后将您重定向回那里和授权。

为什么不简单地在每个 URL 端点上侦听身份验证令牌？对于使用 PageController 或 FrontController 模式的现代 MVC 框架，这应该很简单。

我是否错过了这种方法的缺点？某些框架是否已经使用了这样的系统？给我意见！

【问题讨论】：

大多数框架已经这样做了。收到的每个请求都会在页面处理开始之前检查其身份验证 cookie
#TFD - 正是我的观点；将其发布为答案，我会投票赞成:)
@TFD：我不确定你是否理解这个问题。许多框架都有一个通过用户名和密码进行身份验证的端点，该端点创建了一个存储在您所谓的“身份验证cookie”中的会话。您描述的机制与身份验证关系不大，实际上与会话有关。
back2dos 很受欢迎。我说的不是会话身份验证，而是初始身份验证（它有名字吗？）

【解决方案1】：

为什么不简单地在每个 URL 端点上侦听身份验证令牌？

暂时忽略 end-pont 这个词，这就是开箱即用的基于 Microsoft Forms 的身份验证所做的；在配置中，您指定要保护的站点部分（例如“admin”文件夹等），您可以拥有任意数量的这些部分。

当用户点击其中涵盖的任何内容时（只要 IIS 将其通过管道传输到 ASP.NET 处理器），他们将需要进行身份验证（如果他们还没有）。

我想 ASP.NET MVC 的工作方式完全相同。

不确定这是否能回答您的问题 (?)

【讨论】：

如果我没记错的话，ASP.net 在身份验证时使用了 Login.aspx 页面的 RETURN_URL 参数。我的观点是为什么我不能简单地将我的凭据发布到任何 .aspx 页面并让它在不重定向的情况下对我进行身份验证？
好吧，我想你可以，但你为什么要这样做？ FormsAuth 模块为您完成了这项工作，那么额外的工作在哪里？将身份验证构建到每个页面中——这将增加额外的工作，如果不是，那么肯定会增加额外的复杂性；而且您要节省的只是一个重定向，对吗？如果你认为你可以使用控制器（在 MVC 中）来做到这一点，那就试一试 - 尝试没有害处 :)