8

我已经看到看起来像这样的示例代码，这似乎非常合理：

[Authorize(Roles = "Admin, User")] 
public class SomeController : Controller

但我也看到了几个看起来像这样的例子：

[Authorize(Users = "Charles, Linus")] 
public class SomeController : Controller

我为什么要这样做？我无法想象我想要构建一个预先知道其用户名的系统的任何场景。

4

5 回答 5

3

有一些合法的用途，这里有一个例子：如果你正在构建一个非常简单的站点，它只有一个管理员帐户和一个未经身份验证的帐户，你可以这样做

[Authorize(Users = "Admin")]

这省去了为单个用户构建角色的麻烦。想想 UNIX 风格，其中 root 帐户 (uid 0) 是特殊的，而不是特定的组。

另一个例子是一个简单的一次性应用程序，你在其中测试一些东西。如果您只是想测试您的身份验证页面或类​​似的东西，则没有理由打扰角色。

还有一个原因：测试。您可以仅为您的身份验证构建一个单元测试，而不想对基于角色的框架进行单元测试。（请记住，并不是每个人都在使用默认的成员资格提供程序，并且一些成员资格提供程序非常复杂。）通过为测试用户创建硬编码身份验证，您可以绕过角色框架。

于 2010-02-16T15:30:47.077 回答
1

你不会，硬编码用户是一种难闻的气味。角色存在于这样的事情上。

编辑：我相信，就像当 .net 1.0 以允许/拒绝权限访问整个 web.config 时，那些（或至少应该）用作示例酱，即使我是一群相信的人博客、教程和示例应该只使用良好的做法。

于 2010-02-16T15:27:36.643 回答
1

我能想到的唯一“合法”理由是建立一个后门——无论是出于恶意，还是出于“未来维护”的目的。后者是 Bad Juju，因为它引入了安全风险。前者当然也是Bad Juju :)

于 2010-02-16T15:27:49.550 回答
0

您可能会考虑这样做的几个原因：

  1. 该应用程序的生命周期预计非常短，并且不需要维护。
  2. 有问题的用户可能不属于定义充分的组（如小型企业的情况），并且没有预期的变化。（仍然是非常糟糕的设计，但不会闻所未闻）
  3. 您可能在一个小型应用程序中有多个重载，这些重载需要组内的个人采取不同的行为。

无论如何，它归结为糟糕的设计，你不想这样做。但是界面在那里，因为它是最简单的控制级别。

于 2010-02-16T15:35:26.893 回答
0

我同意大卫·普费弗的观点。

此外，我认为您可以在您的应用程序中定义一组具有非常特定权限和工作的用户-也许是测试目的，也许是性能跟踪......当需求敲门时您会知道; )-。

只是一个不应包含在您的应用程序使用的有效用户集中的组。:)-铁杆方式-

于 2010-02-16T16:23:38.017 回答