为什么要在控制器属性中硬编码用户权限？
我已经看到了如下所示的示例代码，这似乎完全合理：
[Authorize(Roles = "Admin, User")]
public class SomeController : Controller
但我也看到了几个如下所示的示例：
[Authorize(Users = "Charles, Linus")]
public class SomeController : Controller
为什么我要这样做？我无法想象我想要构建一个提前知道其用户名的系统的任何场景。
I have seen example code that looks like this, which seems perfectly reasonable:
[Authorize(Roles = "Admin, User")]
public class SomeController : Controller
But I have also seen several examples that look like this:
[Authorize(Users = "Charles, Linus")]
public class SomeController : Controller
Why would I ever want to do this? I can't imagine any scenario where I would want to build a system that knows its user names in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
它有一些合法的用途，这里有一个例子：如果您正在构建一个非常简单的站点，只有一个管理员帐户和一个未经身份验证的帐户，您可以这样做，
这可以让您省去为以下目的而构建角色的麻烦：单个用户。想想 UNIX 风格，其中 root 帐户（uid 0）是特殊的而不是特定的组。
另一个例子是一个简单的一次性应用程序，您正在其中测试某些内容。如果您只想测试身份验证页面或类似的内容，则没有理由担心角色。
还有一个原因：测试。您可以仅为您的身份验证构建单元测试，而无需对基于角色的框架进行单元测试。 （请记住，并非每个人都使用默认的成员资格提供程序，并且某些成员资格提供程序非常复杂。）通过为测试用户创建硬编码身份验证，您可以绕过角色框架。
There are a few legitimate uses of this, and here's one example: If you're building a really simple site, that simply has an admin account and an unauthenticated account, you could do
This saves you the trouble of bothering to construct roles just for a single user. Think UNIX style, where the root account (uid 0) is special rather than a particular group.
Another example is simply a throw-away application, where you're testing something. There's no reason to bother with roles if you just want to test your authentication page or something like that.
One more reason: testing. You could build a unit test just for your authentication without wanting to unit test your role based framework. (Keep in mind, not everyone is using the default membership provider, and some membership providers are pretty sophisticated.) By creating a hard coded authentication for a test user, you can bypass the roles framework.
你不会的，对用户进行硬编码是一种不好的味道。诸如此类的事情就存在角色。
编辑：我相信，就像当 .net 1.0 使用允许/拒绝权限访问整个 web.config 时，这些（或至少应该仅）用作示例酱汁，即使我喜欢相信这一点的人博客、教程和示例应该只使用良好的实践。
You wouldn't, hardcoding users is a bad smell. Roles exist for things like that.
Edit: I believe that, like when .net 1.0 hit with the whole web.config with allow/deny permissions, those are (or atleast SHOULD ONLY be) used as example sauce, even tho I'm into the pile of people that believe that blogs, tutorials and samples should only use good practices.
我能想到的唯一“合法”理由是建立一个后门 - 要么是为了邪恶，要么是为了“未来维护”的目的。后者是 Bad Juju，因为它引入了安全风险。前者当然也是 Bad Juju :)
The only "legitimate" reason to do that I can think of is building a back-door - either for nefarious, or for "future maintenance" purpose. The latter is Bad Juju as it introduces security risk. The former is Bad Juju as well of course :)
您可能会考虑这样做的几个原因：
生命周期非常短并且没有
需要维护。
有问题的可能不属于
充分定义的组（如
小企业的情况），以及
没有预期的变化。
（仍然是非常糟糕的设计，但它
并非闻所未闻）
小的几个过载
需要不同的应用程序
一个范围内的个体的行为
团体。
无论如何，这都归结为糟糕的设计，你不会愿意这样做。但界面之所以存在，是因为它是最简单的控制级别。
A couple of reasons you might consider doing it:
a very short lifecycle and no
maintenance is required.
in question may not belong to a
sufficiently defined group (as in
the case of a small business), and
there are no expected changes.
(still very bad design, but it
wouldn't be unheard of)
several overloads in a small
application that require different
behaviors for individuals within a
group.
In any case it boils down to bad design and you wouldn't want to do it. But the interface is there because it is the simplest level of control.
我同意大卫·普费弗的观点。
此外，我认为您可以在您的应用程序中定义一组具有非常特定权限和工作的用户 - 也许是测试目的，也许是性能跟踪......当需求敲门时您就会知道； )-.
只是一个不应包含在应用程序使用的有效用户集中的组。 :) -硬核方式-
I agree with David Pfeffer.
In addition I think you could define a set of users with very specific permissions and jobs inside your app -maybe testing purposes, perhaps perfomance tracking... you will know it when the requirement knock the door ; )-.
Simply a group that is not supposed to be contained in the set of valid users used by your application. : ) -the hardcore way-