I'm currently using Ninject2 to bind the various services and repositories in my MVC app. That part seems to be working just fine. Now I'd like to also bind my own class to IAuthorizationFilter and all actions that have the attribute set.
I've created a class that inherits from AuthorizationFilter and Implements IAuthorizationFilter.
I've also add this to my binding module:
Bind(Of IAuthorizationFilter).To(Of MyAuthFilter)
The last time I checked, the Ninject Mvc bits had support for also binding the 4 types of action filters.
Has anyone else done this? Whenever I run the site, the url that invokes the action marked Authorize just redirect to the login page, and never hits the breakpoint in my filter class.
If I were using a custom attribute, it would work, but changing all of the Authorize attributes defeats the purpose of using Ninject every time I want to swap one out of course.
It's not enough to register MVC filters with Ninject; you also have to tell MVC when to execute them. That's why you still need the custom attribute. The injection support in Ninject.Web.Mvc is to allow dependencies to be injected into filters.
Related
I want to apply ASP.Net membership on areas in MVC3.0 project, but I dont want to put [Authorize] in controller. Is this possible if so then how can I achieve this.
You can implement the security checks yourself on the call to each method by overriding OnActionExecuting in a base controller (or each one if you don't want to implement a base controller) and decide whether to allow the call or not. Just out of curiosity why not use [Authorize]?
Yes you can implement global authorization in mvc3. You do this by first writing a global filter that overrides the default AuthorizeAttribute, then registering your custom filter in global.asax
Check out this blog post for more details
We have a legacy application that is part-ASP.NET WebForms and part-ASP.NET MVC.
In order to give all URLs an MVC "style" we've registered a set of routes to map the desired URLs back to the WebForms URLs.
e.g.
routes.Map("somemapping", "NiceUrl/{page}").To("~/UglyUrl/UglyPath/{page}.aspx");
On the MVC Controllers we have implemented performance logging of action methods by way of a custom attribute that inherits from ActionFilterAttribute and overrides OnActionExecuting and OnActionExecuted.
We would like to implement similar logging for the WebForms pages. Is it possible to hook into the routing part and log from there?
Using a System.Diagnostics.StopWatch could solve your problem at a global level.
Here is my proposed solution:
1. In the application BeginRequest instantiate a new instance of StopWatch.
2. Call the start method on the stop watch instance.
3. Place the stop watch in the HttpContext.Current.Items collection
4. In the application End Request, get the StopWatch instance from the httpcontext items, call the stop method, and used the "Elapsed" property of your choice to get the necessary time data that you would like to store
this will provide one single place where you can measure the processing time of all requests, mvc and webforms.
I'm new to asp.net mvc and I was wondering if there was any clean non repetitive way of running a check to see whether a user is logged in when any Action Method on a particular controller is invoked? Also is there a way to stop that method from being invoked and redirecting the user to a specified page?
I'm using a custom authentication method (not Membership Provider) and i'm having trouble finding examples for this type of implementation.
Thanks in advance
Check the [Authorize] attribute System.Web.Mvc.AuthorizeAttribute. Also, the template ASP.NET MVC application created in Visual Studio contains a controller illustrating authorization/authentication techniques.
At what point should I be checking for my cookie in my mvc app? Basically what I wish to do for each request is check to see if there is a cookie and if so show their name on the screen somewhere if not and the page requires the user to be logged in redirect them to a login page.
I DON'T want to use FormsAuthentication as I wish to create and use my own IPrinciple object I 'm just not sure whether I should be setting these in a base controller class or creating my own Authorize attribute and doing the checks in there.
My initial thoughts are that I should be doing this in the base controller class as this is similar to the base page in webforms where I override oninit.
Do not attempt to do authentication in a base controller class. In a situation where an action result is cached, your action will not run at all, and no controller will ever be instantiated. Therefore, authentication done inside the controller is broken by design.
The correct way to customize authentication, for many reasons, is to create a custom authentication provider. I've explained the reasons why and given links to simple examples of how to do this in the post linked above.
In short, using this method:
Has the right level of modularity
Works with caching
Works with regular ASP.NET, as well as with MVC
I'm running into an issue with the Policy Injection Application Block from Enterprise Library in conjunction with ASP.NET MVC.
In my ControllerFactory, I'm creating the controller and then calling PolicyInjection.Wrap on the controller. This gives me back a Transparent Proxy to the controller which manages the call handler chain.
Finally, I cast the Transparent Proxy to an IController and return it.
This seems to work well, except that none of the call handlers I've defined for my controller are executing. (For example I have a Logging Handler configured, but nothing is being logged by PIAB.)
Is my final cast messing this up somehow? How does ControllerBase.Execute() call into my controller? It seems like my proxy should be utilized. Anyone using PIAB on ASP.NET controllers?
I am using PIAB to wrap ASP.NET MVC Controllers, and I'm doing so by calling
PolicyInjection.Wrap<IController>(instance)
which will wrap the IController methods. I'm also using policy injection to wrap the IActionInvoker that gets used as well, which allows for logging the action name.
I have not had success wrapping controllers using the MarshalByRefObject wrapping, but the interface wrapping works like a charm.
If you want additional information, you could create an interface that has all the methods from IController, IActionFilter, IAuthorizationFilter, IExceptionFilter and IResultFilter and then have your controllers implement that interface. Then you could wrap your controllers as that interface and get more calls going through policy injection.
I hope that helps. If you have more specific issues please post.
Seems at least one person uses it :) - ASP.NET MVC Validation using Policy Injection Application Block in Enterprise Library (this is first result BTW)