I am using ASP.NET WebAPI with the built in authentication and identity services that come with the Visual Studio template. I now have it that a user can access the system and be authenticated.
The next logical step is to allow the user to create records. Lets say the user can have a "Project". How can I associate the user with a project at the point the project is created? It seems logical that the project table will just store the user_id provided by User.Identity.GetUserId().
Now, say that a project consists of Tasks. By default the WebAPI will create a Tasks controller, where I post a task. I think I would need to inject some additional information (such as the project id) at the point of creating the task.
But, say someone wants to add a task a project that doesn't belong to them. I need to verify this by loading the project, and checking the user_id field. Now I am adding two repositories to my controller. This seems like a lot of work.
Is it my own laziness that makes this seem hard???
I think this might be a related question, as it seems like you are looking for record-level authorization.
MVC / ASP.Net Best Practice for Record-Level Authorization
There is merit also in using multiple repositories. See here for an example of use.
http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
Here, you would wrap the multiple repositories up within the UnitOfWork class.
I hope this points you in the right direction.
Related
I'm still pretty new to the grails framework and working on legacy application based on grails 2.
I have a domain controller allowing authenticated users to do all basic CRUD actions (create, read, update and delete), with "Read" including list and show.
I need to create another controller/view now allowing any user (non authenticated ones too) to be able to read only (list and show).
I looked around but could not find any "tuto" to do so ...then here's my question:
What would be the best approach to complete this task?
I looked into 2 options:
Option 1
Modifying the current domain controller (class level) #secured annotation in order to annotate only create, update and delete methods. I tried to do so, but it seems like I still have to authenticate which I suspect is related to SpringSecurity "grails.plugin.springsecurity.controllerAnnotations.staticRules" config that I may need to modify too.
Option 2
Create a new controller from scratch (but I guess I can't ask Grails to generate a second domain controller for the same class) then it means quite some work to build up all the data I need.
I'm not even sure if any of the 2 options above is recommended... has anyone faced this problematic (I'm sure many have) and if so ... what was the recommended approach?
Thanks.
I have a project that use the USER_ROLE to give access to different people to different parts of the project. But people still need to login.
I also have another project in C#. There is 2 copies of the same project. The public project is a copy of the main project. However, the public project is accessing the VIEWs set up from the database. It is not accessing the actual tables. So, the public project can have only read only access to a subset of the database records. It is only reading the VIEWs.
I am new to Grails. I don't know if you can set up the domain to access a view or not.
I am thinking outside the box. For your project, is it possible for you to create a new "public-read-only" project. Copy and paste the parts from the main project to the new "public-read-only" project that you want to give people to access.
In this case, your new project is a subset of the main project but it is accessing the records from the actual database tables.
What do you think?
I'm not sure if I just have a solution design issue, but I have an MVC form in an Umbraco project. Umbraco has its own helper extension for forms called BeginUmbracoForm. The form submissions are saved into a regular SQL database outside of Umbraco, so I have a normal MVC project to administer the form submissions (admin's can approve, decline and edit the submissions).
The problem I have is that I'm reusing the Umbraco form within the admin section. It didn't make any sense to create a duplicate form with the exact same fields just for editing.
However, I can't use BeginUmbracoForm in the admin project since it's a normal MVC project. Also I can't post to the same Controller since Umbraco Controllers requires inheriting from SurfaceController.
So basically, I need something like:
if (#Model.IsAdmin)
{
#using ( Html.BeginForm<AdminController>("EditForm") )
}
else
{
#using ( Html.BeginUmbracoForm<UmbracoController>("SubmitForm") )
}
I'm not sure if this is even possible, and I'm thinking I might need to create the admin section within Umbraco.
Creating an admin section within the Umbraco application is a security decision which your domain administrator should make. There is a good case to separate your code base into separate web projects rather than share a single code base.
You would ideally encapsulate your business logic into the domain they serve rather than introduce strict coupling between them. That way your websites could exist in isolation. Be deployed to different end points. Use different technologies and security principals to serve their business function.
Wikipedia: Domain-driven design (Bounded context)
It may seem like an over-engineered solution to a simple problem but I'm sure every developer can recount a project which started out with a few hacks that quickly escalated into a big-ball-of-mud application.
I’m currently building an ASP.NET MVC 5 EF6 blogging web application.
I have two databases and contexts :
-a database for the actual data of my application (blog posts, blog categories, tags, etc) .
-a database for authentification and membership purpose (users and roles).
I am able to authorize a given user the right to add/edit/delete blog posts, using the authorize attribute in the BlogPostcontroller :
[Authorize(Roles=”Administrator,Author”)]
and it works pretty well..
MY GOAL : let’s imagine I want to grant an user the right to add/edit/delete a subset of all the blog post or blog categories (let’s say only to the “Cooking” and “travel” blog categories).
I started to think about creating a navigation property between the user and the blog category entities, but apparently foreign keys between two separate databases are not supported by the entity framework.
Do you guys have an idea of a walk-around for this problem?
Your help will be much appreciated.
This is what you need.
http://typecastexception.com/post/2014/02/19/ASPNET-MVC-5-Identity-Implementing-Group-Based-Permissions-Management-Part-I.aspx
Basically, the privileges is what you will need to configure and associate user roles.
If you want to keep your authorization data separate from your business data, i.e. in 2 separate databases where one contains user information and permissions and the other contains your blog data, then what you actually want to achieve is externalized authorization. That's actually a great intent. After all, do you keep authentication information with your application data? Of course you don't.
Different frameworks give you externalized authorization capabilities. For instance, in .NET, you have claims-based authorization.
You can also take a generic approach and use XACML, the eXtensible Access Control Markup Language. XACML uses attributes (it's an attribute-based access control model as opposed to simply role-based) and combines them into policies & rules to define what can happen. For instance, with XACML, you can write the following rule: A user can edit blog posts he/she owns.
In XACML, you have the notion of an authorization engine called the Policy Decision Point (PDP). That PDP links together all the information it needs to make decisions. In your case, it will use the 2 separate databases and create the relationships on them.
Now, if your use case is simple, using XACML might prove too much. In that case, just use claims-based authorization.
If my site has several user roles say Admin, User, Manager and there are several modules of functionality that may be used by one particular user or by all users how should I go about naming my controllers?
Is it OK to have role based controllers such as an Admin, User and Manager controller as well as controllers for shared functionality such as Products controller?
And for small parts of functionality that is used by only one user role can I keep that inside the user based controller e.g. having all the add/remove/update functionality for product categories can I have that inside the Admin controller or should it have its own controller even though it will only be a few lines of code?
When searching the net for conventions on doing this I am only provided with ways to name the actual file and other sources only explain the controller functionality and not what should and should not be a controller.
If this is subjective I am also happy to take that as an answer, but as it currently stands I am unsure of what is acceptable and whether or not role based controllers are acceptable in the MVC framework.
Personally, I have upgraded my ASP.NET MVC project to version 2-beta release 2 and moved admin related stuff to different area.
This way you can keep your controller names related to their function but run them from dedicated area.
I'm creating a new ASP.NET MVC application. So far I've used the Account controller for actions related to a user's account -- Login/Logout, Activation (like Register, but I use Register for other actions in the site so I've renamed it), Add/Update Contact information. Up to now, though, I've been concentrating on the administrative user views.
I'm at the point where I'm going to start creating the various views that non-administrative users will see. These are rather limited compared to the administrative interface. My inclination is to create a new set of views and associated controller in the User "family" instead of using the Account views/controller. Is this a good idea or should I stick with the Account controller? My feeling is that since this is for ordinary users it should be a separate controller since Account would apply to both ordinary and administrative users.
EDIT: After reading the first couple of responses, my refactored question is:
Do you consider the Account controller to be for administrative actions related to the user's account or for all actions on the user's account? Would you distinguish between membership/role related views/data and application related views/data to the extent of creating a new controller.
Related, but doesn't directly answer my question: ASP.NET MVC Account Controller usage guidelines?
I don't think there's a right or wrong answer here, so I'll give you my opinion.
Technically, either solution (extending the Account controller or creating a new controller) will work just fine.
So I think this is more a question of how the users perceive the functionality. I think it's a good idea to follow the convention that the URI dictates the controller (or vice versa, if you prefer).
If, for example, you'd like to have the "administrative" actions on a separate path, then that should be a separate controller. You might want to do this, for example, if you use an IIS module for authentication or if it makes your log analysis easier.
On the other hand, it might be the case that the users perceive account functions and administrative functions as part of the same family of actions, except that some users have additional features. If so, then that suggests that should be on the same path in the URI and, hence, part of the same controller.
Summing up, I think this is a question you should ask your user representative instead of folks on this site. :)
Update: Regarding your updated question, I would say that it is fairly natural to put an action for changing a user's password on the Account controller, and that action could be invoked by the user herself, not just an administrator. So I wouldn't presume that the Account controller is strictly for administrative tasks. On the other hand, your example of the fund-raising performance is well outside of the scope of membership-related things, so it is not clear that it belongs on Account, either. I'm still leaning towards, "ask your user representative."
In ASP.NET MVC you will usually create controls based on data types rather than access types. For example:
Instead of 2 /Controllers/UsersControl.cs and /Controllers/Admin/UsersControls.cs it is easier to use one common controller for both admins and regular users - /Controllers/UsersController.cs (by setting different [Authorize] attributes and views).
I would keep existing AccountController.cs for encapsulating account related functionality. And just add new UsersController.cs for the rest Users related functionality (which could have methods like OnlineUsers etc.)