Vue 2.0 사용자 권한 제어 솔 루 션

Vue-Access-Control 은 Vue/Vue-Router/axios 를 기반 으로 하 는 전단 사용자 권한 제어 솔 루 션 으로 경로,보기,요청 세 가지 측면 에 대한 통 제 를 통 해 개발 자 들 이 임의의 과립 도 사용자 권한 통 제 를 실현 할 수 있 도록 합 니 다.
설치 하 다.
버 전 요구 사항
Vue 2.0x
Vue-router 3.x
획득
git：git clone https://github.com/tower1229/Vue-Access-Control.git
npm：npm i vue-access-control
운행 하 다.

//  
npm run dev

//  
npm build

개술
전체적인 사고 방식.
세 션 시작 초기 에 로그 인 경로 만 있 는 Vue 인 스 턴 스 를 초기 화 합 니 다.루트 구성 요소 created 갈고리 에서 로그 인 페이지 로 길 을 지정 합 니 다.사용자 로그 인 성공 후 전단 에서 사용자 token 을 가 져 옵 니 다.axios 인 스 턴 스 를 설정 하여 headers 에{"Authorization"을 추가 하 라 고 요청 합 니 다.token}사용자 인증 권 을 확인 한 다음 에 현재 사용자 의 권한 데 이 터 를 가 져 옵 니 다.주로 경로 권한 과 자원 권한 을 포함 합 니 다.이후 동적 으로 루트 를 추가 하고 메뉴 를 생 성하 여 권한 명령 과 전역 권한 검증 방법 을 실현 하 며 axios 실례 에 요청 차단 기 를 추가 하여 권한 제어 초기 화 를 완료 합 니 다.동적 로드 루트 후,루트 구성 요소 가 이에 따라 로드 되 고 렌 더 링 되 며,그 다음 에 전단 인 터 페 이 스 를 보 여 줍 니 다.
브 라 우 저 경로 리 셋 문 제 를 해결 하기 위해 token 을 받 은 후 sessionStorage 에 저장 해 야 합 니 다.루트 구성 요소 의 created 갈 고 리 는 로 컬 에 token 이 있 는 지 확인 합 니 다.있 으 면 로그 인하 지 않 고 이 token 으로 권한 을 가 져 오고 초기 화 합 니 다.token 이 유효 하고 현재 경로 가 접근 할 수 있 으 면 로 케 이 션 구성 요 소 를 불 러 오고 정확하게 보 여 줍 니 다.현재 경로 에 접근 할 권리 가 없 으 면 경로 설정 에 따라 404 로 이동 합 니 다.token 이 효력 을 잃 으 면 백 엔 드 는 4xx 상태 코드 를 되 돌려 야 합 니 다.프론트 엔 드 는 axios 인 스 턴 스 로 오류 차단 기 를 추가 하고 4xx 상태 코드 를 만 나 종료 작업 을 수행 합 니 다.sessionStorage 데 이 터 를 제거 하고 로그 인 페이지 로 이동 하여 사용자 가 다시 로그 인 할 수 있 도록 합 니 다.
최소 의존 원칙
Vue-Access-Control 의 포 지 셔 닝 은 단일 분야 의 해결 방안 으로 Vue/Vue-Router/axios 를 제외 하고 다른 의존 이 없 으 며 이론 적 으로 권한 이 있 는 Vue 프로젝트 에 장애 없 이 응용 할 수 있 습 니 다.프로젝트 는 webpack 템 플 릿 개발 을 바탕 으로 구축 되 고 대부분 새로운 프로젝트 는 검출 코드 를 바탕 으로 계속 개발 할 수 있 습 니 다.설명 이 필요 한 것 은 프로젝트 에 추가 로 도 입 된 Element-UI 와 CryptoJS 는 프 리 젠 테 이 션 인터페이스 개발 에 만 사 용 됩 니 다.그들 은 반드시 권한 제어 와 무관 한 것 이 아니 라 프로젝트 응용 에서 스스로 선택 할 수 있 습 니 다.
디 렉 터 리 구조

src/
 |-- api/     //    
 |  |-- index.js    //    axios  
 |  |-- account.js   //            ，       ./index   axios  
 |-- assets/
 |-- components/
 |-- router/
 |  |-- fullpath.js   //      ，                 
 |  `-- index.js   //        
 |-- views/
 |-- App.vue
 ・-- main.js

 
데이터 형식 약속
경로 권한 데 이 터 는 다음 형식의 대상 배열 이 어야 합 니 다.id 와 parentid 와 같은 두 루트 는 상하 관 계 를 가진다.사용자 정의 형식의 루트 데 이 터 를 사용 하려 면 루트 제어 와 관련 된 실현 을 수정 해 야 한다.

[
 {
  "id": "1",
  "name": "  1",
  "parent_id": null,
  "route": "route1"
 },
 {
  "id": "2",
  "name": "  1-1",
  "parent_id": "1",
  "route": "route2"
 }
 ]

자원 권한 데 이 터 는 다음 형식의 대상 배열 이 어야 합 니 다.대상 마다 RESTful 요청 을 대표 하고 매개 변수 가 있 는 url 을 지원 합 니 다.

[
 {
  "id": "2c9180895e172348015e1740805d000d",
  "name": "  -  ",
  "url": "/accounts",
  "method": "GET"
 },
 {
  "id": "2c9180895e172348015e1740c30f000e",
  "name": "  -  ",
  "url": "/account/**",
  "method": "DELETE"
 }
]

경로 제어
루트 제 어 는 동적 등록 루트 와 동적 생 성 메뉴 두 부분 을 포함한다.
동적 등록 루트
최초의 실례 화 된 루트 는 로그 인과 404 두 개의 경로 만 포함 하고 완전한 루트 는 다음 과 같 기 를 기대 합 니 다.

[{
 path: '/login',
 name: 'login',
 component: (resolve) => require(['../views/login.vue'], resolve)
}, {
 path: '/404',
 name: '404',
 component: (resolve) => require(['../views/common/404.vue'], resolve)
}, {
 path: '/',
 name: '  ',
 component: (resolve) => require(['../views/index.vue'], resolve),
 children: [{
 path: '/route1',
 name: '  1',
 meta: {
  icon: 'icon-channel1'
 },
 component: (resolve) => require(['../views/view1.vue'], resolve)
 }, {
 path: '/route2',
 name: '  2',
 meta: {
  icon: 'ico-channel2'
 },
 component: (resolve) => require(['../views/view2.vue'], resolve),
 children: [{
  path: 'child2-1',
  name: '   2-1',
  meta: {
  
  },
  component: (resolve) => require(['../views/route2-1.vue'], resolve)
 }]
 }]
}, {
 path: '*',
 redirect: '/404'
}]

그러면 그 다음 에 첫 페이지 와 하위 경로 들 을 가 져 와 야 합 니 다.생각 은 전체 프로젝트 의 전체 경로 데 이 터 를 미리 로 컬 에 저장 한 다음 에 사용자 권한 에 따라 전체 경 로 를 선별 하 는 것 입 니 다.
선별 의 실현 방향 은 먼저 백 엔 드 를 되 돌려 주 는 경로 데 이 터 를 다음 과 같은 해시 구조 로 처리 하 는 것 이다.

let hashMenus = {
 "/route1":true,
 "/route1/route1-1":true,
 "/route1/route1-2":true,
 "/route2":true,
 ...
}

그 다음 에 로 컬 전체 경 로 를 옮 겨 다 니 며 상기 구조의 key 형식 으로 경 로 를 연결 합 니 다.hashMenus[route]를 통 해 경로 가 일치 하 는 지 여 부 를 판단 할 수 있 습 니 다.App.vue 파일 의 getRoutes()방법 을 구체 적 으로 볼 수 있 습 니 다.
백 엔 드 에서 돌아 오 는 경로 권한 데이터 가 약속 과 다 르 면 자체 적 으로 선별 논 리 를 실현 해 야 합 니 다.실제 사용 가능 한 경로 데 이 터 를 얻 을 수 있 으 면 됩 니 다.최종 적 으로 addRoutes()방법 을 사용 하여 경로 인 스 턴 스 에 동적 으로 추가 하고 404 페이지 의 모호 한 일치 에 주의 하 십시오.
동적 메뉴
경로 데 이 터 는 네 비게 이 션 메뉴 를 만 드 는 데 직접 사용 할 수 있 지만 경로 데 이 터 는 루트 구성 요소 에서 얻 을 수 있 습 니 다.네 비게 이 션 메뉴 는 index.vue 구성 요소 에 존재 합 니 다.분명히 우 리 는 특정한 방식 으로 메뉴 데 이 터 를 공유 해 야 합 니 다.방법 이 많 습 니 다.일반적으로 Vuex 를 먼저 생각 하지만 메뉴 데 이 터 는 전체 사용자 세 션 과정 에서 변 하지 않 습 니 다.이것 은 Vuex 의 가장 좋 은 사용 장면 이 아 닙 니 다.또한 불필요 한 의존 을 최소 화하 기 위해 가장 간단 하고 직접적인 방법 으로 메뉴 데 이 터 를 루트 구성 요소 인 data.menuData 에 걸 고 홈 페이지 에서 this.$parent.menuData 로 가 져 옵 니 다.
또한 네 비게 이 션 메뉴 는 항목 아이콘 을 추가 하 는 수요 가 있 을 수 있 습 니 다.이 는 경로 에 meta 데 이 터 를 추가 하여 이 루어 질 수 있 습 니 다.예 를 들 어 아이콘 class 나 유 니 코드 를 경로 meta 에 저장 하면 템 플 릿 에서 meta 데 이 터 를 방문 하여 아이콘 탭 을 만 들 수 있 습 니 다.
다 중 역할 시스템 에서 발생 할 수 있 는 문 제 는 서로 다른 역할 에 이름 은 같 지만 기능 이 다른 경로 가 있다 는 것 이다.예 를 들 어 시스템 관리자 와 기업 관리자 가 모두'계 정 관리'라 는 경로 가 있 지만 그들의 조작 권한 과 목표 가 다 르 기 때문에 실제 적 으로 두 개의 서로 다른 인터페이스 이 고 Vue 는 여러 개의 경로 가 같은 이름 을 가 질 수 없 기 때문에 경로 의 name 은 반드시 구분 해 야 한다.그러나 구 분 된 name 을 프론트 메뉴 에 표시 하 는 것 은 아름 답지 않 습 니 다.서로 다른 캐릭터 가 같은 메뉴 이름 을 가 질 수 있 도록 이 두 경로 의 meta.name 을 모두'계 정 관리'로 설정 하고 템 플 릿 순환 시 meta.name 을 우선 사용 하면 됩 니 다.
메뉴 의 구체 적 인 구현 은 views/index.vue 를 참고 할 수 있 습 니 다.
보기 제어
보기 제어 의 목 표 는 현재 사용자 권한 에 따라 인터페이스 요소 의 표시 여 부 를 결정 하 는 것 이 고 전형 적 인 장면 은 각종 조작 버튼 에 대한 표시 제어 이다.보기 제 어 를 실현 하 는 본질은 권한 검증 방법 을 실현 하고 요청 권한 을 입력 하 며 출력 이 허 가 될 지 여부 입 니 다.그리고 v-if 나 jsx 또는 사용자 정의 명령 에 맞 춰 각종 보기 통 제 를 유연 하 게 실현 할 수 있 습 니 다.
전역 검증 방법
검증 방법의 실현 자 체 는 매우 간단 하 다.백 엔 드 에서 제 시 된 자원 권한 에 따라 판단 하 는 것 이 아니 라 최적화 방법의 입 출력 에 중심 을 두 고 용이 성 을 향상 시 키 는 데 중심 을 둔다.실천 을 통 해 최종 적 으로 사용 하 는 방안 은 권한 과 요청 을 동시에 유지 하고 검증 방법 은 대상 배열 을 매개 변수 로 하여 권한 이 있 는 불 값 을 되 돌려 주 는 것 이다.
요청 대상 형식:

//      
const request = {
 p: ['get,/accounts'],
 r: params => {
 return instance.get(`/accounts`, {params})
 }
}

권한 검증 방법$has()호출 형식:

v-if="$_has([request])"

권한 검증 방법의 구체 적 인 실현 은 App.vue 에서 Vue.prototype.$참조has 방법.
권한 검증 방법 을 전역 적 으로 혼합 하면 프로젝트 에서 v-if 와 쉽게 결합 하여 요소 디 스 플레이 통 제 를 실현 할 수 있 습 니 다.이러한 방식 의 장점 은 유연성 입 니 다.권한 을 검증 할 수 있 을 뿐만 아니 라 판단 식 에 실행 시 상 태 를 더욱 다양한 판단 을 할 수 있 고 v-if 가 데이터 변화 에 응 하 는 특징 을 충분히 이용 하여 동적 보기 통 제 를 실현 할 수 있 습 니 다.
구체 적 인 실현 세부 사항 은 Vue 기반 백 스테이지 시스템 권한 제어 에 관 한 장 을 참고 합 니 다.
사용자 정의 명령
v-if 의 응답 특성 은 양날 의 검 을 사용 하 는 것 입 니 다.표현 식 이 실 행 될 때 자주 트리거 되 기 때문에 실제 사용자 세 션 주기 에 권한 이 변 하지 않 습 니 다.따라서 검증 권한 만 필요 하 다 면 v-if 로 불필요 한 연산 이 많이 발생 할 수 있 습 니 다.이 경우 보기 로 불 러 올 때 한 번 만 검사 하면 됩 니 다.사용자 정의 명령 을 통 해 이 루어 질 수 있 습 니 다.

//    
Vue.directive('has', {
 bind: function(el, binding) {
 if (!Vue.prototype.$_has(binding.value)) {
  el.parentNode.removeChild(el);
 }
 }
});

사용자 정의 명령 내 부 는 여전히 전역 검증 방법 을 호출 하지만 요소 초기 화 시 한 번 만 실행 되 는 것 이 장점 입 니 다.대부분의 경우 사용자 정의 명령 을 사용 하여 보기 통 제 를 실현 해 야 합 니 다.
요청 제어
요청 제 어 는 axios 차단 기 를 이용 하여 이 루어 진 것 으로 월권 요청 을 전단 에서 차단 하 는 것 이 목적 이다.원 리 는 요청 차단기 에서 이번 요청 이 사용자 권한 에 부합 되 는 지 판단 하여 차단 여 부 를 결정 하 는 것 이다.
일반 요청 의 판단 은 매우 쉽 습 니 다.백 엔 드 에서 돌아 오 는 자원 권한 형식 을 옮 겨 다 니 며 request.method 와 request.url 이 일치 하 는 지 직접 판단 하면 됩 니 다.매개 변 수 를 가 진 url 에 대해 서 는 어댑터 를 사용 해 야 합 니 다.여 기 는 프로젝트 수요 전후 단 에 따라 일치 하 는 협상 을 해 야 합 니 다.어댑터 형식 을 약정 한 후에 차단기 에서 먼저 매개 변 수 를 가 진 url 을 약정 형식 으로 처리 한 다음 에 권한 을 판단 해 야 합 니 다.프로젝트 에서 다음 과 같은 두 가지 마스크 형식 을 실 현 했 습 니 다.

1.   ：/resources/:id
   ：/resources/1
 url: /resources/**
   ：          ，         id
 
2.   ：/store/:id/member
   ：/store/1/member
 url：/store/*/member
   ：            ，            id

첫 번 째 형식 에 대해 주의해 야 할 것 은 url 이'/aa/bb'라 는 요청 을 하려 면 기본적으로'/aa/*'로 처리 되 어 권한 검 사 를 할 수 있 습 니 다.만약 에 여기 있 는'bb'가 매개 변수 가 아니 라 url 의 일부분 이 라면 url 을'/aa/bb/'로 바 꾸 고 마지막 에'/'를 추가 해 야 합 니 다.
차단기 의 구체 적 인 실현 은 App.vue 의 setInterceptor()방법 을 보십시오.
프로젝트 에 다른 마스크 형식 이 필요 하 다 면 차단기 에서 해당 하 는 검 측 과 전환 방법 만 실현 하면 됩 니 다.
시연 및 설명
프레젠테이션 설명:
DEMO 프로젝트 에 서 는 동적 메뉴,동적 경로,단추 권한,차단 요청 을 보 여 줍 니 다.
프레젠테이션 프로젝트 백 엔 드 는 랩 2 에서 mock 데 이 터 를 생 성 합 니 다.로그 인 요청 은 보통 POST 방식 이 어야 하지만 랩 2 의 프로 그래 밍 모드 에서 GET 가 아 닌 요청 파 라 메 터 를 가 져 올 수 없 기 때문에 GET 방식 으로 만 로그 인 할 수 있 습 니 다.실제 프로젝트 에 서 는 시 뮬 레이 션 을 권장 하지 않 습 니 다.
또한 로그 인 후 권한 을 가 져 오 는 인 터 페 이 스 는 추가 적 인 파 라 메 터 를 가지 고 있 지 않 습 니 다.백 엔 드 는 요청 헤드 에 있 는 token 정보 에 따라 사용자 인증 을 실현 할 수 있 지만 랩 2 의 프로 그래 밍 모드 에서 headers 데 이 터 를 가 져 올 수 없 기 때문에'Authorization'파 라 메 터 를 추가 하여 아 날로 그 데 이 터 를 만 들 수 있 습 니 다.
테스트 계 정:

1. username: root
 password:   
2. username: client
 password: