In previous projects, the common way of cooperation between the front and back ends is that the front end provides the page and UI with a little DuangDuangDuang effect, and the back end builds the framework data structure and data interaction (data interaction has intersection between the front and back ends), whether it is .net, java or PHP can provide one-to-many front-end services. However, in the new form, the front-end framework is used in the project, and the development situation is different. For example, what I want to say is that this development is completed under the angular framework, and the mode is provided by the back-end. Service and API documents, page and data interaction and logical processing are completed by the front end. The front end is like a complete programmer. In this process, you will encounter previously unexpected problems (if you have not done back-end development), such as page permission control. I have to say that it is more complicated to use the front-end method to make these settings, because this data, that is, the 'marking' of these permissions, can be obtained directly when the back-end is running, that is, just click to obtain field data a.b. came out, but the front-end can only obtain it through http requests, which is cumbersome and cumbersome;
In fact, there are many ways to obtain page access rights in ng, each with its own pros and cons. The most commonly used one is the interceptor, which makes the front-end Do some operations before or after sending an http request to the backend, such as globally monitoring whether the user is logged in, the login page that will be redirected if not logged in, and the page can be accessed after logging in; the use of interceptors is often combined with background data, that is, obtaining the latest 'mark' to determine what operations should be done on this page or the next page; and here I use a front-end control method without data interaction. The idea is to define the pages that can be accessed at different levels/stages. Interception is done at the routing point. If access permissions at different levels/stages are clearly defined, you can refer to this method. The code is as follows:
...... app.run(['$rootScope', '$state', '$window', function($rootScope, $state, $window) { $rootScope.$on('$stateChangeStart', function(event, toState, toStateParams) { //用户访问等级阶段, 0 1 2 Array.prototype.contains = function(needle) { for(i in this) { if(this[i] == needle) return true; } return false; } var status=new Array("user.a","user.b","user.c","user.d","user.e","user.f","user.g"); var status0=new Array("user.a","user.b"); var status1=new Array("user.c","user.d"); var status2=new Array("user.a","user.b","user.c","user.d"); if (status.contains(toState.name)) { if(initObj.getStatus()=="0"){ if(!status0.contains(toState.name)){ event.preventDefault(); $state.go('user.approve'); } return; } if(initObj.getStatus()=="1"){ if(!status1.contains(toState.name)){ event.preventDefault(); $state.go('user.result'); } return; } if(initObj.getStatus()=="2"){ if(!status2.contains(toState.name)){ event.preventDefault(); $state.go('user.result'); } return; } } }) }]) ......
As shown in the code, add state monitoring to the run of ng (I am here Using an-route-ui), detection is performed when a route jump is detected. The accessible 'marked' status array envisaged here contains accessible pages/routes at each level/stage, for example, the status is The complete set that needs to be detected, status0, 1 and 2 are the permission access sets of different levels/stages, that is, the hash value of the route jump in ng, which also represents the accessible pages. Using this detection method, there is no Users with access rights cannot access certain pages. For example, the hierarchical stage configuration of user a is status1, including user.c and user.d. initObj.getStatus() returns his status code of 1. When he wants to access user .a page, it will enter the judgment of initObj.getStatus()=="1", but its configuration accessible page does not include user.a, that is!status1.contains(toState.name)(toState.name Return to the page you want to jump to (return to user.a here), then enter the following operation, enter the public page or prompt page, the principle is basically like this;
Of course, this method is very different from the back-end control. It is safe but not rigorous, because even if the script in the project is released, compressed and obfuscated, you can still find traces of the settings here if you browse carefully, and the script is editable before running, which will cause a big vulnerability; however It is enough to use these configurations in some small projects, and even if someone modifies the status configuration, the data and other things are requested from the backend. If the status is incorrect, the data cannot be requested, so it is really dark to compromise the database. The front-end script interception is just for fun and testing;
Continue to explore other optimization methods. If there are experts who have better methods, you can share them; let’s stop here first.