the train of thought has been stated in the previous few floors, basically, it is to write the route normally first, and then judge whether to show it to the user or not according to the permission. Let me add a practical one.
- encapsulate the left column into a component, such as nav:
2.props
vue
1.router.beforeEach,
2.concatrouter.addRoutes
3.routes
""
vue-routeradd
demomock
1json;
2;
3 ;
4;
5index.vue ;
:
:tree
:tree
:
:
background control should be good, flexible, data-driven
can be changed direction, that is, admin has the highest permissions, with all permissions, you can see all the sidebar navigation, that is, there are all routes in the page, and other permissions can be matched through the data passed from the backstage, and the sidebar navigation can be displayed and hidden accordingly. Vue has not been used much. Like adding v-if=false to the navigation label, it is more appropriate to add the route control in vue to control the url of the current route. Simply hide the navigation
the solution on the same floor
I also apply it in the project. The trouble only lies in the match negotiated between you and the backend
the logical idea on my side is to hide all the data first, display the corresponding routes after obtaining the data, and then verify the permissions of the route.to targets through the navigation guards. I wrote a vue plug-in to inject my permission verification method into the vue instance to do a more detailed button-level front-end permission check.
the two solutions are actually similar. The former may be more troublesome for local developers, and it is difficult to work when there is no interface.
both methods have unified disadvantages and cannot make corresponding changes to the permissions of currently logged-in users in real time.
in the final analysis, the front end is only to assist in verifying permissions to optimize customer experience. After all, only the back-end permission verification is valid
encapsulate the left menu into a component and then control the display of the menu through the background data.
two scenarios.
Scheme 1, route all permissions are registered, and the display navigation id, is dynamically obtained. In order to prevent users from entering the address bar directly, a route interceptor is added.
Plan 2: register routes strictly according to permissions. Before vue instantiation, obtain registrable routes asynchronously, and then register
.
is actually the part of rights management. Different users may have different menus and different items are displayed in the menu bar on the left. The left encapsulates the component, and the data is processed through the back end to return different menu items.
ask the value of component, and how to send it to the background
there are such requirements in general background management systems
1, roles can be configured, each role has different menu permissions, data is stored in the database
2, roles are assigned to users when users are created
3, menu permissions are returned in the background when users log in pages (read)
4, and the front end renders menus according to permission data
premise that, as mentioned by several people upstairs, the front end also needs to have a complete route map
.
