Why should I hard code user permissions in my controller attributes?

Question

I saw an example of code that looks like it seems perfectly reasonable:

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

But I also saw a few examples that look like this:

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

Why should I do this? I can’t imagine any scenario in which I would like to create a system that knows its usernames in advance.

Answer 1

There are several legitimate uses for this, and here is one example: if you create a really simple site that just has an administrator account and an unauthenticated account, you can do

 [Authorize(Users = "Admin")] 

This eliminates the need to create roles for only one user. Think of a UNIX style where the root account (uid 0) is a special, not a specific group.

Another example is just a dropping application where you are checking something. There is no reason to worry about roles if you just want to check your authentication page or something like that.

Another reason: testing. You can create a unit test only for your authentication, not wanting the unit test of your platform based on roles. (Keep in mind that not everyone uses the default membership provider, and some membership providers are quite complex.) By creating strong coded authentication for the test user, you can get around the role structure.

Answer 2

You wouldn’t do it, users of hard coding have a bad smell. There are roles for such things.

Editing: I believe, for example, when .net 1.0 got with all web.config with permissions to enable / disable, they (or at least SHOULD ONLY be) are used as an example of sauce, even if I get into a bunch of people who believe that blogs, tutorials, and samples should use only good methods.

Answer 3

The only "legitimate" reason I can think of is to build a back door - either for infamy or for "future service." The latter is Bad Juju, as it introduces a security risk. The first is, of course, Bad Juju :)

Answer 4

A few reasons you might think about this:

• The application is expected to have a very short life cycle and no maintenance is required.
• The user (s) in the question may not belong to a sufficiently specific group (as in the case of a small business), and there are no expected changes. (still a very poor design, but it would not be unheard of)
• You may have several overloads in a small application requiring behavior for individuals in a group.

In any case, it comes down to poor design, and you do not want to do this. But an interface exists 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 tasks within your application - perhaps testing, perhaps tracking performance ... you will know this when the request is knocked on the door; ) -.

Just a group that should not be contained in the set of valid users used by your application. :) - hardcore way -