vue-router permission control (simple method)

Controlling front-end permissions in vue-router is a common requirement:

1. There is a way to directly complete the judgment on the backend, provide a page list and operation list, and render it on the front end, but this solution is not elegant and has a high degree of coupling between the front and back ends.
2. A more common approach is to separate the login page from the router, write a permission control file specifically, load the router according to the user's permissions after logging in, and then pass the permissions into various components as parameters to control the rendering of elements. This method is more reasonable and has no extra overhead. It is just that it is more troublesome to write a login page and permission control file independently, especially for some small projects.

We hope there is an easier way. At this time, we sort out the requirements. Our main goals are:

1. Menu bar control, rendering page menus that can be entered according to permissions;
2. Operation button permission control, no display if there is no operation permission;
3. If someone enters a page without permission by directly clicking on the link or entering the address, block it;

The first and second goals are easy to achieve. Pass the permission list to the corresponding component and judge through v-if. What needs to be solved is the interception problem of overprivileged pages. In the common practice above, in order to achieve interception, a login page is written separately, and the route is loaded according to the permissions after logging in. In this way, the route without permissions will not load at all, so it is directed to the 404 page.

So, the question now is, how can there be an easier way?

Obviously, if we don't want to write the login page separately, the router will complete the loading before logging in. If the unauthorized page cannot be automatically directed to the 404 page through the router, we can only manually boot. Once your ideas are clear, there is no pressure to realize:

According to the life cycle of the vue component, we can make permission judgments on the mounted hook. If the user permission list passed through props does not have corresponding permissions, the page will be jumped to 404:

mounted () {
     if (!this.check_user_privilege (current_page)) {
       this.$('Insufficient permissions');
       this.$('404');
     }
 }

Of course, in fact, vue-router also provides hook methods when page jumping. Globally, there are beforeEach, afterEach, etc. We want to use it directly in the component, so we can use the beforeRouteEnter method to make judgments when entering the page, such as:

beforeRouteEnter (to, from, next) {
     next(vm => {
       if (!vm.check_user_privilege (current_page)) {
         vm.$('Insufficient permissions');
         vm.$('404');
       }
     })
   },

For details, please refer to [Document].

Of course, in this example, using the hook provided by vue-router is better than writing the judgment conditions directly on mounted, because next in the beforeRouteEnter method requires calling component parameters and is executed after mounted execution. We often need to load page data on the mounted hook. In order to avoid waste, it is better to make a judgment first.

Compared with common methods, simple methods have extra overhead, mainly because they need to fully load the route and make a judgment after loading the page. However, from the perspective of writing code, it seems that it is more logically more cost-effective, because there is no need to write another file that centrally controls permissions. As for the permission judgment of each page, it is something that you originally had to do in the menu bar, and extending to different pages is not a burden.

Will there be any side effects? It seems that there is no such thing as for the time being. If you judge the page permissions at the beginning of mounted, there will be no problem of loading overprivileged data. Moreover, the data permissions need to be judged separately by the backend, so the frontend should not worry.

The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.