The authority pool of shiro is in the doGetAuthorization method of realm, and the authority string SET of the current user is found from the DB and put into the info of shiro.
The permission pool of the filter is in the session. After logging in, the permission set of the current user is put into the session (SESSION scheme).
When finally using this permission pool----
When shiro is called in places such as @RequiresPermissions, <shiro:hasPermission>, subject.isPermitted(), etc., it will match in the permission pool according to the parameters passed in. As a result, a large number of annotations will be brought, and the workload to be programmed to write various permission parameters is considerable.
The filter, in its interception method, intercepts the URL, and then matches it according to the permission pool. There is no additional workload, and they are all handled uniformly. The advantage of this scheme is that log processing can also be performed according to the URL in the interceptor (the URL must be unique, the operation name can be obtained according to the key, the time, user, and operation name are all available, and the status can be returned in the targetMethod of the filter. JSON is obtained, such a log record is generated).
I personally think that the interceptor scheme may be more convenient in terms of authorization authentication. But it doesn't mean that shiro is bad. Shiro provides a series of permission functions, such as remberme, session management, etc., which you can't do with interceptors.
Similarly, log processing can also be handled in a way similar to annotation AOP, or through filters. Similarly, I still think that interceptors may be more convenient, and annotations also require a lot of extra work (at least each method needs to be Write a comment, because the method name cannot be unique, so you can't use the key to get the operation name like a URL, so you need to write the operation name dead. There are so many methods.... The workload is also considerable)
(However, the interceptor has a point of attention when doing logs. It needs to maintain the relationship between the URL and the operation name. You can maintain the buttons in the menu table. Of course, this is more reasonable. The menu table should have button information.)
-----If you want to maintain the authority of the button, you can do this: the authority is given to only the menu, the query button below the menu, and the button B in the window below the menu (button A in the pop-up window is not needed). When requiresPermissions, you can use , on the return page controller method of A to collect all the permission strings in the window, indicating that the window can only pop up if you have the permission of the sub-buttons in all windows. In this way, the log is also accurate to CURD (not what pop-up windows are also recorded), and the buttons are not too messy. Note that there are usually AJAX requests in the window. At this time, if the permission is not enough, it should not be returned to JSP, it should be JSON, and the relevant base class of shiro should be rewritten.
----If you don't want to maintain button permissions and want to record button logs, you only need to not display the button on the permission grant page.
---The most important information of the log, the operation name can be done as follows: recursively get the menuName of the parent node, then spell your own menuName, and then put it into the map, the key is the url, (it can also be a permission string , you need to maintain the authority of the button), and then put the map into the cache (because the general URL will not change, the menuName will not change; and there are quite a lot of URLs, and the amount of data is large. It is most suitable for caching. ).
To sum up, the interceptor makes logs and relies more on the database. If you don't want to maintain button permissions, you have to display the menu filter button. AOP does logging, which is less dependent, and the metadata will not change during the life cycle, which is more suitable for caching. Anyway, each has its pros and cons. In the final analysis, the interceptor and AOP are actually the same, both PROXY.