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.
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.
Let's say that I have an MVC view that has one set of features available to non authorized users, and an extended set of features that is available to authorized users. Currently, I have implemented this by marking up my view with
#if(User.IsInRole(...)) {...}
in several places in the view file. This wasn't a big deal when it was just 2 or 3 things that authenticated users could do beyond the non-authenticated functionality, but now I have this all over the place in a "dashboard" type of page. It seems to be getting kind of messy.
Is there a cleaner or more elegant way to implement this? I am using viewmodels. I am wondering if I should use different viewmodels/views based on role, but then using different viewmodels seems like it might be more difficult to maintain. I am not sure what the best practice is for this, and I am open to ideas.
Edit
One example of what I am doing: I have several lists/tables that allows managers to edit the record, so the code adds an extra
<td>
for the manager-allowed actions. Another use case: when the manager is signed in, an employee name is now an actionlink instead of just text.
What you could try is encapsulating each portion of the view that will be interchanged based on roles into partial views. This has worked well for me in the past, and is much cleaner when trying to troubleshoot code as opposed to seeing a bunch of #if statements in a single view.
Hmmm. I have this idea. You need list of dashboards enumerations where you have a property like RolesAllowedToAccess (string[])
On the view you can foreach by dashboards enumerations where RolesAllowedToAccess contains current user role.
After you can render partials for each of dashboards. Make sence?
I have a question about how to design my controllers properly.
Project is fairly simple: blog, immage gallery with categories and images inside them, news secion.
However I don't know how to organize my controllers for this because I want to make somewhat admin panel where administrators can edit, add and modify these things. I've came up with 3 scenariosu so far...
Admin panel will have links to site/controller/edit, but layout for these action results will be different from standard one.
Admin controller will have all these actions like BlogAdd, BlogEdit so that url will be something like /site/admin/blogedit.
Create copies of Blog controller in admin folder so url will be like /site/admin/blog/edit - i sense problems with routing since 2 controllers with same name does not sound like a good idea, however I like ho URL looks in this situation.
What I'm trying to make is CMS somewhat similar to wordpress, where blog creation,editing and deletion is completely separated from default blog itself.
I suggest you stop thinking about URLs and Controllers being a 1->1 relationship. This will make things MUCH easier and less confusing. You can make the URLs work however you want with MVC's routing mechanism and there's no reason to restrict your controller design/organization because of the URLs you want, because you can always adapt the routing to with with the URLs you have in mind.
While building the website, just focus on the controllers (and the general interface) and ignore the URLs until you get to that point, and then when you come up with a good URL scheme go into the routing system and add the routes to connect to your existing controller actions as you want.
Once you code out your blogging engine you will have a much better idea of the user workflow and will probably find different ways to organize your URLs, and you can then reorganize your URLs without touching the controllers themselves.
As to your first requirement:
There are two ways to do this depending on your end goal. If your goal is to display the same core content, but have different user options available (different overall layout, additional buttons on the page, etc..) then the best idea is really to just pass in an IsAdministrator property in your view model, and make the slight changes to the page based on if that's true or false. The reason is because you still (most likely) want the core of the page to be the same, and this keeps you from duplicating code that is related to the core data (data that's being displayed for both admins and non-admins).
Edit: So in summary, organize your controllers based on what makes it easier to develop with, not based on how the user interacts with the system with. You can always change the latter, changing the former is harder and will make maintenance annoying.
You can create Areas in your MVC project and have your admin functionality in a controller in your admin area.
This will allow you to easily seperate your administration functionality from your general blog functionality.
That's how I'd do it.
Why don't you keep the routes the same and handle the different roles via security? For example:
/blog/name-of-topic/view to view a topic (all users)
/blog/name-of-topic/edit to edit a topic (only enabled for logged in users)
/blog/add to create new topics (only enabled for logged in users)
You can handle these actions in a single controller and decorate the actions that require logged users via the [Authorize] attribute. Same thing with the links on your views, you would enable the links to edit and add topics only to visible users.
You could still have a separate panel to allow admins to hit the aforementioned add/edit links .
I am a bit new to ASP.NET MVC and I have a bit of an ordeal. I am developing a website with several roles in it and of course the logic and gui that the user gets depends on the role (duh).
There are 10 separate roles in this application. They do share most of the same functionality but some screens will be different depending on which roles they are in.
Heres my question. All examples and tutorials I've read on the internet and the Apress book that I have been reading show an example how to implement roles with one role (Admin) in which the common way is to provide an Admin Controller (or even Admin area) for the authorized section of the site. However, what if there are 10 roles? Do I really need to code up 10 separate controllers?
Let me help the question by giving detail what is being developed. There will be a menu and the menu items will be filtered by role of what views(or pages) they can and cannot get.
The from what they select, it will provide them a restricted view(or authorized page) which from within will provide a plethora of functionality limited to just that role.
I know there are several different ways to do this, I just want to know what is the recommended or "clean" way.
Have any of you been in this situation and if so, how did you organize the logic for multiple roles? Separate all roles to separate controllers? Have few controllers but just apply authorize filtering on the action methods? Apply the role filtering within the views or partial views and leave the controllers alone?
Unfortunately there are little resources for how to implement several roles out there, I just want to know how to do it the "correct" way in terms of separating the logic.
I would put the pieces of functionality into partial views. Have one controller per piece of website and load partial views based on the role and what should be exposed.
I would only stray from that if you have an excessive amount of differences, like an administrator would possible have. Then I typically make an area to encapsulate that functionality.
Regardless of the controller separation I would definitely use partial views to minimize duplication of similar code. You will reap the benefits when you need to maintain that code.
Use Authorize on the action methods and apply the roles allowed for the operation.
Depending on what's appropriate for the scenario, build a list of available actions from the controller and send that to the view as part of the view model. In some cases its more appropriate to send a simpler view model that tells the view whether each operation is allowed i.e. CanDelete, CanEdit, CanViewDetailedInfo etc.
I'd start with that, and depending on the actual complexity re-factor to any combination of:
An ActionFilter that populates the available actions / instead of explicitly doing it in the controller
Use reflector to look for the list of roles applied in authorize / so you only specify roles once
Your own html helpers that take authorization into account. So when you declare an action link, its only output when the action is supported.
There's so much I'm enjoying with asp.net MVC 2...but sometimes I feel like I'm trying to find a needle lurking in that haystack by beating it with a stick.
So. I have a list of objects. I have a strongly-typed view, which lists those objects. I have data annotations coming back just lovely, and all is well and good.
Now I want to create an admin view of that very same list. Do I:
Create a new view, called AdminList, and put all the administrative goodies in there (CRUD!), in a new action in the same controller, and decorate both actions with [Authorize], or
Modify the existing view, so that it dynamically detects the role of the current user and enables/disables admin functionality appropriately, or
Some third option?
I'm looking for the cleanest, least brittle approach.
TIA!
I would recommend you externalizing common parts in reusable partials and in the main view depending on the user role enables/disables admin functionality. Also it's not the view responsibility to test the user roles, this should be done by the controller and include this information into the view model (like a boolean property ShouldDisplayAdminPanel) so that the view decides whether or not include partials.