How to control the permissions of the RESTFUL interface provided by the back end in the separation of the front and back end?

encountered a problem today

I have a system, which is role-based permission control.
the front end naturally controls the view that should be displayed according to the role.
but in order to prevent others from directly using httpclient access, then the background must also control the corresponding permissions.
when interacting, all I can know is who the user is
so that I can know his role.

then I want to know how control is controlled at the code level.
how to control that a role can access only one type of url?

my idea is
1. The background needs to maintain the url of the whole system (that is, the interface provided)
2. Maintain the views needed by the system (menus, buttons, etc., because the use of the interface is basically bound to the view)
3. View and role binding, user and role binding

it would be troublesome to do so
1. The workload of maintaining the url of the whole system is very large
2. The workload of the interface URL corresponding to the maintenance view is also very large
3. The resource-based RESTFUL interface has many parameters on url, and the regularization will be more complex, and there are many cases

.

later, I saw that permission control can be done like this in SHIRO

in an interface, such as springmvc interface

@RequireRoles("admin")
@RequestMapping("/{id}")
public void get(){
   xxx
}

how can I do this? if the roles needed for the direct interface are intercepted at the interface layer using Annotation, the workload will be greatly reduced. But the kind of role that we have seen so far can only be hardcode.. Cannot be obtained dynamically from the database.

so there are three questions.
1) how do you deal with this situation?
2) is it reasonable for me to have a very heavy workload? Is there an improved method
3) is it possible for shiro to control role permissions directly at the interface layer and obtain the required roles from the database?

Warriors, thank you very much!

-the following add-
the front and rear ends are verified by token, which is for sure. What I want to ask is that after the token verification is passed,
then I have
1. Currently visited URL
2. Current user, role of current user

I find it troublesome to maintain URL for roles. To ask if there is a better solution


role-based access control is not a good idea. For more information, please see this article: https://stormpath.com/blog/ne.

my project also uses shiro, not role-based, but permission-based. To put it simply, it goes like this:

  1. every url, menu, and button is a resource,. This resource has a corresponding permission

  2. .
  3. role has permission (several)

  4. the way to determine whether the role can get resources is simple, just see if the role has a corresponding resource permission

  5. here only permission is dead


generally manages the resource URL , provides maintenance permissions for the management platform, and uses interceptor/filter to verify whether users have the corresponding permissions.

  1. Why do you want to get roles from the database? Because permissions change? In this case, you have to maintain the resources, or it is impossible to implement dynamic permissions.

  2. permissions are relatively simple, just like roles in Tomcat Manager , so there's no problem with using hard coding directly.

the most important thing is what the requirements look like.


I think these are two questions.

first prevent the interface from being called by others, which can be restricted by using the mechanism of token . If there is no token or token incorrect, 403 will be returned.

all that's left is the question of permissions, using shiro, spring security, and so on, and you can use session to distinguish between users with different permissions.


  1. the server generates a token to return to the client, and the client takes this token, backend for unified processing with filter for every request.

  2. if you can solve problem 3, then problem 2 is meaningless;

  3. remember that shiro can control permissions at the code level. Take a look at the documentation.


permissions have multiple granularities, action permissions, data permissions, permissions under different state conditions, which cannot be controlled only at a certain level. Common RBAC,ACL can only be partially controlled, or should be applied flexibly according to their own conditions. There is no panacea.


you can consider using Spring Security or Shiro for permission management. For specific operations, you can look up information on the Internet


now there is a new permission framework called jCasbin ( https://github.com/casbin/jca.). JCasbin adopts the design idea of metamodel and supports a variety of classical access control schemes, such as ACL, RBAC, ABAC, and RESTful API control. Web frameworks such as Spring Boot and JFinal are now supported. If you need Chinese documents, you can read this article: https://blog.csdn.net/hsluoyc., or search on Baidu: jCasbin


supports the second floor. In general, we use uri as a unified resource management
recommend an authentication framework for restful api: sureness
- https://github.com/tomsun28/s.
provides a for restful api , no framework dependency , You can dynamically modify permissions , multiple authentication policies , faster , easy to use authentication framework ^ _ ^

Menu