I am working on an ASP.NET MVC 3 application where users can be assigned different roles for different asset types. They are able to view assets that belong to different groups (asset type), one at a time.
Depending on the asset type of the asset that is being viewed, I would like to update the Principal's roles array to only have the roles that the user has been assigned for that asset type.
I am thinking I would do an authorization filter that takes care of looking up the roles the user has been assigned to based on the asset being viewed and loading them into the roles array. This way, the roles array will always reflect the permissions they have for the asset being viewed.
Then from the view, I can hide/show different parts of the page depending if they are in a specific group (User.isInRole)
Would this be the right approach to switching roles for the user depending on the asset type?
If these roles need to be applied across a request, and you can get the items identifier from header, query string, cookie, or session, i would suggest possibly adding an httpmodule that would bind to the AuthorizeRequest event. In that point you will want to provide your IPrinciple object with its custom implementation
the IsInRoles based on your rules.
Would this work, I'm mainly just guessing about your setup and on an ipad.
Related
In my application the users are split in 2 macro categories: Customer and Backoffice, every category has a subset of role, for example MANAGER and USER for Customer type and different ones for the Backoffice type.
So a user could be a Customer with a MANAGER role or a Backoffice with, for example, a SALES role.
Every Spring + Cognito guide on web uses cognito:groups to map the Spring ROLE, but for my case I would need to nest groups which is not possible on Cognito.
I've been thinking to use 2 custom attributes ( writable only by the admin) to set the category and role of the user respectively.
My question is, is there any disadvantage to using attributes instead of the groups?
One major concern is, those custom attributes won't be available as claims in the access token. But groups are available. So If you plan to use acces_token you may have to consider that.
There are some other minor considerations that I can think of, which may or may not be related your implementation:
Maximum number of custom attributes per user pool is 50.
Once created, you can not edit the name, min/max length and mutable property of the custom attribute. Also we can not delete that.
Even though nested groups are not supported in Cognito, is it not an option to create groups like: category_role? example: Customer_ MANAGER?
I will have two or 3 types of users on the front (Clients, Providers, and Manufacturers) and each user will have different set of features and data profile.
Which is the best strategy you imagine for creating the content types for each type of user?
In my head, I have in mind to create 3 content types related to Users and set a field for USERTYPE, and the front requests the rest of the profile on the other content type.
What do you think?
Also related to security, is it possible to set access to contents according to different user types?
Thank you.
It's depending of you want to do and depending of your application need.
You can also create roles, one for Clients, one for Providers and one for Manufacturers. You will be able to manage who can do what.
For the accounts entity I have different account types.
However I need to make some of these records read only only based on the account type, as these records will be slaved in CRM.
However the user should still have ability to create other types of accounts that will be mastered in CRM.
I was thinking to do this via security role however when giving create or edit permission on the account entity user can still create accounts of any type or edit existing slaved data.
What would be the best way to make slaved data read only?
Use business rules to lock all fields based on the type?
Like you said, this cannot be achieved with security role, since the requirement is based on a field value.
Disabling all the form fields in bulk - You can do this in javascript quickly, or may be with Business rules one by one. Verify the field value on form load for your certain slaved value account type, then disable the controls by iterating each one of them.
Still subgrid, webresource, iframes will be editable.
I'm creating an app in blade, where I need two different user types. (Landlord and tenant).
I'm currently using the laravel auth, and I have a dropdown menu which lets a user select there type upon registration. I need the users to interact with eachother.
Should I have seperate models for the landlord, and the tenant.
Why use a different table? Just use a userType column and you're good! If you do go with two table structure, you will have to manage two different structure and need all your logics done twice...
Is it possible to change the attributes of form view for specific user groups in form view tag, like in form tag, readonly="{('user_group','=','some_group')}">
I need to make a form view read-only for s specific user group but only from front-end. Records are updated from code by that user belonging to that specific user group from back-end. and if i disable updating the records of that model by that user group in my security file, that user is not able to modify the records even from back-end.
Best way to do this is by defining a new group that have only read access on that model and add to that user you will save a lot of typing and a lot of your time.
Because what you really asking is to remove edit write for a specific user.