in asp.net MVC architecture,
can i write AuthorizeAttribute on the method of model class?
i am trying to do this but its not working.
please let me know how can i do this..?
No, you can apply authorization to controller's actions only.
You should check there if the user can access the actions performed on the model and then do it. Putting authorization on the model is not good, because the same model may be used in different actions, and the user may be authorized to some, and denied some other.
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
Just starting out with ASP.NET MVC. I'm working on a customer portal for our (FogBugz) helpdesk system. I understand that decorating my ActionResults with [Authorize] will require that the user is logged in, but what I'm not sure on is how best to ensure that a user can only access their own calls.
Once a user is authorised I can get their username from the User object, so should I be passing that from my controllers into the business layer and authorizing there, or is there a better way to do this (like a custom AuthorizeAttribute)?
i think you should read this article below. it maybe help you to find the right way.
Rick Anderson # MSDN Blog.
or
How do i create a custom AuthorizeAttribute that is specific to the the area, controller or action?
I have an existing ASP.NET application with lots of users and a large database. Now I want to have it in MVC 2. I do not want to migrate, I do it more or less from scratch. The database I want to keep and not touch too much.
I already have my database tables and I also want to keep my LINQ to SQL-Layer. I didn't use a MembershipProvider in my current implementation (in ASP.NET 1.0 that wasn't strongly supported).
So, either I write my own Membershipprovider to meet the needs of my database and app or I don't use the membershipprovider at all.
I'd like to understand the consequences if I don't use the membership provider. What is linked to that? I understand that in ASP.NET the Login-Controls are linked to the provider. The AccountModel which is automatically generated with MVC2 could easily be changed to support my existing logic.
What happens when a user is identified by a an AuthCookie? Does MVC use the MembershipProvider then?
Am I overlooking something?
I have the same questions regarding RoleProvider.
Input is greatly appreciated.
With MVC it is simple to bypass the Membership and Role provider framework altogether. Sometimes it is easier to do this than to implement custom Membership/Role providers, in particular if your authn/authz model doesn't quite fit the mold of those providers.
First, you should realize that you don't need to write everything from scratch, you can use the core Forms authentication API, which can be used independently of the Membership/Role provider framework:
FormsAuthentication.SetAuthCookie -
Call this after user has been
authenticated, specify the user name
Request.IsAuthenticated - Returns
true if SetAuthCookie was called
HttpContext.Current.User.Identity.Name - Returns the user name specified in the call to SetAuthCookie
So here is what you do in MVC to bypass the Membership/Role provider:
Authentication: In your
controller, authenticate the user
using your custom logic.If
successful, call
FormsAuthentication.SetAuthCookie
with the user name.
Authorization: Create a custom
authorize attribute (deriving from
AuthorizeAttribute) . In the
AuthorizeCore override, implement
your custom authorization logic,
taking the user in
HttpContext.Current.User.Identity.Name
and the roles defined in the Roles
property of the AuthorizeAttribute base class.
Note you can also define properties on your custom
authorization attribute and use that in your authorization logic.
For example you can define a property representing roles as enumerated values
specific to your app, instead of using the Roles property which is just a string.
Affix your controllers and actions with your
custom authorize attribute,
instead of the default Authorize
attribute.
Although you most likely can do this without a custom membership provider, I'm not sure that you save that much effort. Until I read this blog post I thought implementing one was hard, but it's really not. Basically you do this:
Create a class that inherits System.Web.Security.MembershipProvider.
MembershipProvider is an abstract class, so you are readily shown what methods need to be implemented.
The names are pretty self explanatory, so you can probably more or less copy your existing logic.
You might end up doing more than you need with this approach - but on the other hand, anything you might want to use now or in the future that requires a membership provider will already have its needs met.
The source of the SQLMembershipProvider is available here http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx. Take that as a base.
It looks a bit much at first, but you only have to implement the methods you need.
Yes the AuthCookie is used. Yes its a good idea to use the MembershipProvider, because it is well known by other developers.
There are thinks I dont like about it: For example It is not possible to have a transaction that spans the creation of a user by the membershipsystem and some other data in your own datbase. But still it works well.
Say that you have a controller named Buildings and that every user in the system have a set of buildings that he/she administrates. If you have an Edit-action in your controller that you can access with /Buildings/Edit/{id} is there a nice and simple way to implement some kind of authorization attribute that only allows access to this site if the id you are trying to edit is a part of the logged in users set of buildings. Or do you have to handle this yourself in your controller?
regards
Freddy
You can use ActionFilterAttribute.
Check out this SO too
Check this post: asp.net mvc attributes actionfilterattribute and why you might want to use them
Sure you can, you can derive from the Authorize attribute to define your own authorization for an action method. There's an example of using it in this blog post.
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.