为什么我会在控制器属性中硬编码用户权限？

Question

我看过这样的示例代码，看起来非常合理：

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

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

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

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

Answer 1

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

[Authorize(Users = "Admin")] 

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

另一个例子就是一个扔掉的应用程序，你正在测试一些东西。如果您只是想测试您的身份验证页面或类​​似的东西，没有理由去担心角色。

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

Answer 2

你不会，硬编码用户是一个难闻的气味。对于类似的事情存在角色。

编辑：我相信，就像.net 1.0在整个web.config中使用允许/拒绝权限命中时，那些（或者至少应该只是）用作示例酱，即使是我进入堆认为博客，教程和样本应该只使用良好实践的人。

Answer 3

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

Answer 4

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

1. 应用程序应该有 生命周期很短，没有 需要维护。
2. 用户 有问题可能不属于 充分定义的群体（如 小企业的情况），和 没有预期的变化。 （设计仍然非常糟糕，但它 不会闻所未闻的）
3. 你可能有 小的几个重载 需要不同的应用程序 个人的行为 基。

在任何情况下，它归结为糟糕的设计，你不会想要这样做。但界面就在那里，因为它是最简单的控制级别。

Answer 5

我同意David Pfeffer的说法。

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

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