I have been looking around but i don't see any spec for this, maybe i search a wrong keyword. But i'm here so i should ask something.. :)
I'm familiar with Authorize Attribute, but I think it only apply to Actions. What should i do if i want my whole application to authorize first before getting access to any actions?
It will be very pain to just repeat in every action to put [Authorize] tag on top of them.
Thank you very much
It is not quite correct that AuthorizeAttribute applies only to actions. It can also be applied to classes containing actions. If you have a base controller type for your application (which can be abstract, if you like), and every other controller is a subtype of that base type, then your entire application now requires authorization, with just a few characters of typing.
You should find a way to make AuthorizeAttribute work for you; this is the standard way of doing authentication in ASP.NET MVC.
No, you can mark your controller with AuthorizeAttribute like an action. Check out here.
Related
I have created a class CustomAuthorizeAttribute:AuthorizeAttribute for authorization, but I am unable to authorize in the razor view like #if(User.IsInRole("some role"));, but what I want is #if(CustomAuthorizeAttribute(My Parameters)) for my authorization.
How to do that?
AuthorizeAttribute works by placing it on an action method, a controller, or as a global filter. It is not possible to use MVC filters inside of views (or at least not without a lot of work).
I suggest you ask a different question and narrow it to your requirements. There must be some reason why you are attempting this, but it is impossible to work out what you need to do (or if there is a much simpler approach) from your question.
I use the AuthorizeAttribute and roles (Identity). I want to hide ActionLinks based on user roles. I found solutions with HtmlHelpers like this. But I really don't like those solutions because the view must know about the required roles. This means the roles are defined twice: in the controller and the view.
Does anyone know a better solution? Can I e.g. get the roles from the AuthorizeAttribute in the view or in the controller (maybe use ViewBag to transfer to view). I thougt about reflections, but this is bad when it comes to performance as the controller code is executed for every request.
The nicest solution would be without logic in the view anyway..
One possibility is to use MvcSiteMapProvider for your menu. It has a built-in security trimming feature that automatically hides links according to AuthorizeAttribute. If you don't like the built-in HTML helpers, you can customize the templates and/or build your own HTML helpers that hide links based on node accessibility.
Or, if you don't want to use a 3rd party library, you can reverse engineer the AuthorizeAttributeAclModule to make your own implementation.
Full Disclosure
I am a major contributor of MvcSiteMapProvider.
I have an ASP.NET MVC application with a controller that looks something like this:
[Authorize]
public class MyController : Controller
{
IMyRepository myRepository;
public MyController(IMyRepository myRepository)
{
this.myRepository = myRepository;
}
...
}
I have noticed that this constructor gets called prior to authenticating the user, so if you are visiting the page for the first time the constructor is called prior to redirecting you to the login screen. There are many problems with this, the login page loads slower, the site has greater exposure to DOS attacks, and I'm a little nervous about unauthenticated, unauthorized users being able to invoke code 'behind the walls' sort of speak.
I could check the incomming request in the constructor and bail unless the user is authorized, but I'm using IOC (Windsor) which makes that a bit tricky, my repository is going to be initialized regardless of whether or not I store the instance, so I'd be left checking authentication in each repository's constructor. Is there an easy way to get .NET MVC to authenticate the user prior to invoking the constructor? I'm thinking something like adding [PrincipalPermission(SecurityAction.Demand, Authenticated = true)] to the controller, but there might be a better way still.
EDIT:
Ok, not too happy about it, but the show must go on for now. I cannot delay initializing the repository until some later point in time from within the controller. When your controller uses IOC as in my example, you get an already instantiated implementation of your repository interface at the time that the controller is instantiated. If I had control over the repository being created, I could easily just call IsAuthenticated, no need for a new method. In order to take control of the repository initialization you would have to implement some sort of lazy/late initialization in the repository itself in each implementation. I do not like this solution because it adds needless complexity and more importantly coupling between the controller and repository. The repository implementation(s) may be used in other contexts where lazy initialization doesn't make sense IMHO.
The controller needs to be instantiated before authorization happens because it can act as its own authorization filter via the OnAuthorization method. Changing that behavior would involve replacing some core parts of the mvc pipeline. Is there a particular reason why you think the AuthorizedAttribute might not do its job?
Another option you could consider is initializing your repository in the OnActionExecuting of your controller method instead of in the constructor.
You can use HttpModules (or HttpHandler) to authenticate the request earlier in the pipeline.
MSDN: Introduction to HTTP Modules
MSDN: Implementing Intercepting Filter in ASP.NET Using HTTP Module
EDIT
With the introduction of OWIN you can configure the entire request pipeline middleware and put authorization at whatever stage you want. Same idea as above but a bit easier to implement.
Paul,
the instantiation of the controller is many many processes ahead of any actions on the controller being callable. even if the would be attacker attempted to benefit from this time lapse between instantiation and the login-screen, the controller action would only be able to run if the action had the authority to do so i.e. i'm assuming that your actions or controller all have the [Authorize] attribute on them.
I don't think you need worry too much about this and can rest easy, tho' i understand your obvious curiosity.
In terms of DOS attacks, it really should not matter -- after the first hit, which one sees alot when developing, the controller instantiation should be cheap. Well, unless you are DDOSing yourself by having the constructor do actual work such as pre-caching database lookups . . .
ASP.Net MVC Controllers have several methods of forwarding control to another controller or action. However, all of them cause a client redirect, with a 302 and a new browser request.
Why is there no internal "call another controller's action" functionality, without getting the client involved? I'm pretty sure that the php CodeIgniter framework also lacks this functionality.
The best reason that I can come up with is that ultimately it's unnecessary, since any code you want to call into could be factored out into someplace common, and in ASP.Net MVC at least, the operation might be quite expensive. But a lot of people ask about this, and it seems like it would ultimately be a convenience.
So... lots of smart people designed these frameworks. There must be some good reasons for not having this?
In Codeigniter you can set custom routes and stuff to direct certain URLs to other controllers/actions, but I think you mean in the middle of a controller function to jump into another?
If there is any business logic you have, especially if it's going to be reused, it should go into a model, not a controller. You can also specify different views in a controller depending on some condition or something. If you have repeating code that doesn't 'fit' into a model, then it should probably end up as a static helper function, or in a library class.
So yeah, I think you're right on when you say:
The best reason that I can come up with is that ultimately it's unnecessary, since any code you want to call into could be factored out into someplace common
This forces you into staying within the MVC pattern.
Best to keep your controllers lightweight anyways.
Well, at least in ASP.NET MVC, controller actions are just C# methods called in creative ways. So you can just explicitly call another controller action, like so:
Sample controller:
public class SampleController : Controller
{
public ActionResult Foo()
{
return View("foo");
}
public ActionResult ShowMeFoo()
{
return Foo();
}
}
Now, I think in most cases one wouldn't want to do this. Considering urls as a RPC interface for your app, it should forward to a different url when getting different results. Doesn't apply to all cases, but can appy to most.
I suspect it may go against the REST idea, everything is a resource. If you wish to perform a server transfer, you can as well offer an extra url for that resource. This way the client will know on that specific url he will receive one particular representation of a resource, and not under circumstances something else. That makes sense actually.
I have the following Filter on my Controller:
[Authorize(Roles="Admin")]
public class AdminOnlyController : Controller
{
// stuff
}
I showed a couple of guys here at work what I'm doing, and a huge debate emerged with some of the guys claiming that Authorization should not be a responsibility of the Controller. This is the way I learned to do it, according to the book Pro ASP.NET MVC Framework by Steven Sanderson.
None of the other guys were able to suggest how it should be done, other than that it was wrong.
Is it? Is there a better way?
The simple answer is yes - that is the best way. The Controllers' Actions are the end point for ALL requests to the application. It makes perfect sense to put the authorisation there.
You could farm the authorisation out to IIS, but that worked better when access was controlled to files (.aspx etc). Now we have a MVC with which you have to control access to multiple actions within one controller.
There's two ways to assign authorization. The controller class or the ActionResult. As opposed to how else you could do it, I'm not very sure.
I don't really see the side of the argument where you argue against the controller managing who's authorized to invoke it. By having the authorization nearby, you follow theory (I forget the name) of 'declare it as close as you can to where you use it.'
It might depend on the background of your coworkers. If they're really used to using something like XML, then I bet they're suggesting some type of configuration file - which seems to be induced due to a more corporate type of programming.
On the flip side, There could be a benefit to extracting out authorization somewhere else (but within the application) so that it's easily modifiable, in case you end up adding a "PaidUser" for example. In that case you wouldn't have to go to every controller to update it. However, I think you end up falling into an all or nothing approach - where it's either in the controller, or it's all in some configuration file. Unless you create a scheme that your central authorization can be overridden by a controller's authorization, except at that point, you can easily lose control of who's managing what and you end up in an 'authorization soup' of sorts.