Why would I hard-code user permissions in my controller attributes?

Question

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.

Answer 1

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.

Answer 2

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 :)

Answer 3

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

[Authorize(Users = "Admin")] 

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.

Answer 4

A couple of reasons you might consider doing it:

1. The application is expected to have a very short lifecycle and no maintenance is required.
2. The user(s) 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)
3. You may have 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.

Answer 5

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-