Hello, this is more of a design question than specific to ABP, but there are some smart people here so I wanted to hear your answers.
A user may be able to edit a Tenants details. So we need a "Edit Tenant" page. If a user can edit their own tenant, and other tenants (they are a kind of Admin), then they can use the same "Edit Tenant" page for all cases. When the user clicks save, I only need to check that they have the "Edit All Tenants" permission.
Some users, can only Edit their own Tenant. These users can still use the normal "Edit Tenant" page, however, this means that when the user tries to save, I need to check that the user has the "Edit Own Tenant" permission. But this requires creating a whole separate flow for the case where a user is editing their own Tenant. Which means at least putting an "if tenantId is session.tenantId" into the service methods. This feels wrong.
So my question comes down to, shouldn't it be some kind of CanUserEditTenant(input.TenantId) ?
This would require a lot of work under permissions, but would mean that all views, controller actions and service methods could be clean from any authorization work, and duplicate code. It would mean that all editing of a tenant would be one view, one controller action and one service method. The service method would call this function to check the permission.
Am I on the right track? If so, where should these "permission checking" functions be written? They will end up being quite elaborate.
6 Answer(s)
-
0
It seems what I am actually leaning towards is ACL (Access Control Lists), I have no experience with this stuff, but I would like to know where/how this would be easily implemented with ABP.
This post: <a class="postlink" href="http://stackoverflow.com/questions/1335315/access-control-in-asp-net-mvc-depending-on-input-parameters-service-layer/1336404#1336404">http://stackoverflow.com/questions/1335 ... 04#1336404</a>
-
0
So far, I can understand that we need to be able to call a function on an Entity to be able to determine if this is doable: Product.CanEdit
This makes sense, but where exactly would be the best place to implement this? It feels like it would be easier to place it into the creation of Product.Dto, so that all other subDtos can also use it.
Any ideas?
-
0
How about, functions in the PermissionManager:
CanEditProduct(int Id) CanDeleteProduct(int Id) CanEditAnyProductsFromTenant(int Id)
?
-
0
Ok, It is not ACL, but UAC (User Access Control) I am looking for: <a class="postlink" href="http://stackoverflow.com/a/1342406/1079267">http://stackoverflow.com/a/1342406/1079267</a>
So, it is suggested that this is implemented in the repositories. I can see two ways of doing this.
1) Create different repositories for different groups of a single entity. OurProductsRepository, LocalSuppliersProductsRepository
2) Inside the repository create permission functions which take the user and the Id of the Entity and compare them using MAD LOGIC to decide if they can or cannot edit them. This would require adding an Edit property to the Entity (which isn't stored in the database).
Any suggestions about how else to implement this in such a way, using ABP?
-
0
Hi,
I think it is better to make this control in your AppService method before the edit operation. Don't put methods like CanEditProduct, CanDeleteProduct or CanEditAnyProductsFromTenant because they are entity specific. If you follow this approach, you will have so many methods in the PermissionManager.
Instead of doing this, you can define permissions like CanEditProduct, CanDeleteProduct and use them attributes on your application service method.
You can check CanEditAnyProductsFromTenant in the application service method's beginning.
-
0
<cite>ismcagdas: </cite> Hi,
I think it is better to make this control in your AppService method before the edit operation. Don't put methods like CanEditProduct, CanDeleteProduct or CanEditAnyProductsFromTenant because they are entity specific. If you follow this approach, you will have so many methods in the PermissionManager.
Instead of doing this, you can define permissions like CanEditProduct, CanDeleteProduct and use them attributes on your application service method.
You can check CanEditAnyProductsFromTenant in the application service method's beginning.
I understand, and this is actually the approach I have ended up taking.
This is actually what I was doing before I learned about Abp, but I started to think it was the wrong way since I learned about permission based stuff and whatnot. Now it turns out it was more complex than that and my initial solution was a good one.
Thanks
