In previous projects, the common way of coordination between front and back ends was to provide the effect of pages and ui plus a little DuangDuangDuang in the front and back ends, and build the framework data structure and data interaction (the data interaction has intersections before and after ends), whether it is .net, java or PHP can provide front-end services one-to-many, but in the new form, the project uses the front-end framework, and the development situation is different. For example, what I want to say is the development completed under the angular framework. The model is that the back-end provides services and API documents. The page and data interaction and logic processing are completed by the front-end. The front-end is like a complete programmer. In this process, you will encounter unexpected problems before (if you have not done back-end development), such as page permission control. It has to be said that using the front-end method to do these settings is more complicated, because the data in this aspect, that is, the "mark" of these permissions, can be obtained directly when the back-end runs, that is, the data in the field is just a click, and the front-end can only be obtained by http request, which is cumbersome and troublesome;
In fact, there are many ways to access pages in ng, each with its pros and cons. The most commonly used interceptor is an interceptor. The interceptor allows some operations before or after sending http requests to the backend, such as global monitoring of whether the user is logged in, and the login page that needs to be redirected without logging in, and you can access the page by logging in; the use of interceptor is often combined with backend data, that is, obtaining the latest "mark" to determine what operations to do on this page or the next page; and here I use a front-end control method, without data interaction. The concept is to define pages that can be accessed in different levels/stages, intercept in the route, and refer to this method for some clearly defined access permissions of different levels/stages. The code is as follows:
......
(['$rootScope', '$state', '$window', function($rootScope, $state, $window) {
$rootScope.$on('$stateChangeStart', function(event, toState, toStateParams) {
//User access level stage, 0 1 2 = function(needle) {
for(i in this) {
if(this[i] == needle) return true;
}
return false;
}
var status=new Array("","","","","","","");
var status0=new Array("","");
var status1=new Array("","");
var status2=new Array("","","","");
if (()) {
if(()=="0"){
if(!()){
();
$('');
}
return;
}
if(()=="1"){
if(!()){
();
$('');
}
return;
}
if(()=="2"){
if(!()){
();
$('');
}
return;
}
}
})
}])
......
As shown in the code, add state monitoring to the run of ng (I use an-route-ui here), and when the monitor reaches the route jump, it will be detected. The status array that can be accessed here is designed to contain pages/routs that can be accessed at each level/stage. For example, status is the complete set that needs to be detected, status 0, 1 2 are the permission access sets of different levels/stages, that is, the hash value of the route jump in ng, which represents the accessible page. Using this detection method, users without access permissions cannot access certain pages. For example, the hierarchical stage configuration of user a is status1, including sum, () returns his status code 1. When he wants to access the page, he will enter the judgment of ()=="1", but his configuration accessible page does not include it, that is!() (return to the page to be redirected, return here), and then enter the following operation to enter the public page or prompt page. The principle is basically this;
Of course, this method is very unsafe and not rigorous in terms of backend control, because even if the script in the project is published and compressed and confused, you can still find the settings traces here after a closer look, and the script is editable before running, which will cause great vulnerabilities; however, these configurations are enough in some small projects, and even if someone modifies this status configuration, the data is requested from the backend, and the status is incorrect, and data cannot be requested. Therefore, it is considered to be really dark to attack the database. Intercepting from the front-end script is just a playful test;
Continue to explore other optimization methods, and there are great masters and better methods to communicate; let’s come here first.
Also, Singles' Day is here, I wish all single dogs a chance to get out of singleness as soon as possible. Hehe~~~~