How to Set page access permissions in Angularjs and angularjs Permissions
In previous projects, a common combination of front-end and back-end is that the front-end provides a page and ui with a DuangDuangDuang effect, the data structure and interaction of the backend construction framework (the front and back ends of the data interaction have an intersection), whether it is. net, java or php can provide one-to-Multiple front-end services. However, when a front-end framework is used in a new project, the development situation is different, for example, I want to talk about the Development completed under the angular framework. The mode is that the backend provides services and api documentation, and page and Data Interaction and logic processing are completed by the front-end, the front-end is a complete programer, and unexpected problems will occur in this process (if no backend development is done), such as page permission control. I have to say, it is difficult to use the frontend method to make these settings, because the data in this regard, that is, the 'tag' of these permissions, can be directly obtained during backend operation, obtain field data like. click B, and the front-end can only be obtained using http requests, which is tedious and troublesome;
In fact, there are many ways to access the page in ng, each of which has its own advantages and disadvantages. The most useful method is the interceptor, which allows the Interceptor to perform operations before or after sending an http request from the front end, for example, to globally monitor whether a user logs on or not, you can access the logon page if you do not log on to the logon page. The use of interceptor often works with background data, that is, getting the latest 'tag ', to determine what operations are required for this page or the next page. Here, I use a front-end control method without data interaction, the concept is to define the pages accessible at different levels/stages, and intercept the routes. For some clearly defined access permissions at different levels/stages, 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) {// user access level stage, 0 1 2Array. 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 the state listener in ng's run (an-route-ui is used here), and check the route jump when listening, the "accessible" status array here contains the pages/routes that can be accessed at each level/stage. For example, status is the complete set to be checked, status0 and 1 2 are permission access sets at different levels/stages, that is, the hash value of the routing jump in ng, which represents accessible pages. Using this detection method, users without access permissions cannot access some pages. For example, the hierarchical configuration of user a is status1, which contains the user. c and user. d, initObj. getStatus () returns his status code 1 when he wants to access the user. when page a is displayed, initObj is displayed. getStatus () = "1", but its configuration does not include user. a, that is! Status1.contains (toState. name) (toState. name: the page to jump to. Here, the user is returned. a) Next, go to the following operation to go to the public page or prompt page. The principle is basically like this;
Of course, this method is very insecure and not rigorous with the back-end control, because even after the project scripts are mixed with release compression, you can still find the trace of the settings here, and the script can be edited before running, which will cause a lot of vulnerabilities. However, these configurations are enough in some small projects, even if someone modifies the status configuration, the data and everything are requested from the backend, And the status is incorrect, the data cannot be requested. Therefore, it is really black to break the database, the interception of previous scripts is just a test;
Continue to explore other optimization methods. If you have any better methods, please come here first.
Also, we wish the majority of single dogs to take off their tickets as soon as possible. Hey ~~~~