이전 프로젝트에서 프런트엔드와 백엔드 간의 일반적인 협력 방식은 프런트엔드가 약간의 DuangDuangDuang 효과가 있는 페이지와 UI를 제공하고 백엔드가 프레임워크 데이터 구조와 데이터 상호작용(데이터 상호작용이 있음)을 구축하는 것이었습니다. .net이든 Java이든 PHP이든 일대다 프런트엔드 서비스를 제공할 수 있지만 새 형식에서는 프로젝트에서 프런트엔드 프레임워크가 사용됩니다. 예를 들어 제가 말하고 싶은 것은 이 개발은 Angle 프레임워크 하에서 완료되며, 프론트엔드는 서비스와 API 문서, 페이지와 데이터 상호 작용 및 논리적 처리를 제공한다는 것입니다. 프론트엔드는 완전한 프로그래머와 같습니다. 이 과정에서 페이지 권한 제어와 같은 이전에 예상치 못한 문제(백엔드 개발을 수행하지 않은 경우)에 직면하게 됩니다. 즉, 이러한 설정을 수행하기 위해 프런트 엔드 방법을 사용하는 것이 더 복잡합니다. 왜냐하면 이 데이터, 즉 이러한 권한의 '표시'는 백엔드가 실행 중일 때 직접 얻을 수 있기 때문입니다. field data point a.b 바로 나왔는데 프런트엔드에서는 http 요청을 통해서만 얻을 수 있어서 번거롭고 번거롭습니다.
사실 ng에서 페이지 접근 권한을 얻는 방법은 여러가지가 있습니다. 자체적인 장단점이 있으며 인터셉터가 더 일반적으로 사용되지만, 인터셉터를 사용하면 프런트 엔드가 백 엔드에 http 요청을 보내기 전이나 후에 일부 작업(예: 사용자 로그인 여부)을 전역적으로 모니터링할 수 있습니다. 로그인하지 않은 경우 점프하고 로그인 후 페이지에 액세스할 수 있는 로그인 페이지는 종종 배경 데이터와 조정됩니다. 즉, 이 페이지에서 수행할 작업을 결정하기 위해 최신 '마크'를 가져옵니다. 또는 다음 페이지에서는 데이터 상호 작용 없이 프런트 엔드 제어 방법을 사용합니다. 아이디어는 다양한 수준/단계를 정의하는 것입니다. 액세스할 수 있는 페이지는 여러 수준에서 명확하게 정의된 액세스 권한에 대해 차단됩니다. /stages에서 이 메소드를 참고할 수 있습니다.
...... 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; } } }) }]) ......
코드에 표시된 대로 ng의 실행에 상태 모니터링을 추가합니다( 여기서는 an-route-ui를 사용합니다. 경로 점프가 감지되면 여기에서 '표시'에 액세스할 수 있습니다. 예를 들어 상태에는 각 레벨/단계에서 액세스할 수 있는 페이지/경로가 포함되어 있습니다. 감지해야 하는 전체 집합입니다. status0, 1 및 2는 서로 다른 수준/단계의 권한 액세스 집합입니다. 즉, 해시 값은 이 감지 방법을 사용하여 액세스할 수 없는 사용자를 나타냅니다. 예를 들어, user.c 및 user.d를 포함하여 사용자 a의 계층적 단계 구성은 status1입니다. initObj.getStatus()는 그의 상태 코드가 1임을 반환했습니다. 페이지에서 그는 initObj.getStatus()=="1"이라는 판단을 내리지만 그가 구성한 액세스 가능한 페이지는 user.a를 포함하지 않습니다. 즉, status1.contains(toState.name)(toState.name은 페이지를 다음으로 반환합니다!) 점프하면 user.a)가 반환되고 다음 작업을 입력하고 공개 페이지 또는 프롬프트 페이지에 들어가십시오. 원칙은 기본입니다.
물론 이 방법은 매우 안전하지 않으며 측면에서 엄격하지도 않습니다. 백엔드 제어의 경우 프로젝트의 스크립트가 릴리스되고 압축되고 난독화되더라도 주의 깊게 탐색하면 여기에서 찾을 수 있기 때문입니다. 추적이 설정되고 실행 전에 스크립트를 편집할 수 있으므로 큰 허점이 발생합니다. 그러나 일부 소규모 프로젝트에서는 이러한 구성을 사용하는 것으로 충분하며 누군가 상태 구성을 수정하더라도 데이터와 모든 것이 백엔드에서 요청되는 경우 상태가 올바르지 않으면 데이터를 요청할 수 없으며, 따라서 데이터베이스를 손상시키는 것은 실제 해킹으로 간주됩니다. 프론트 엔드 스크립트를 가로채는 것은 단지 재미와 테스트를 위한 것입니다.
계속해서 다른 최적화 방법을 탐색해 보세요. ; 먼저 여기로 가보겠습니다.