머리말
Angular는 단일 페이지 응용 프로그램이므로 대부분의 리소스는 처음부터 브라우저에로드되므로 확인시기에 더 많은주의를 기울이고 확인을 통과 한 사용자 만 해당 인터페이스를 볼 수 있도록해야합니다.
이 기사의 인증은 사용자가 로그인했는지 여부를 결정하고 서버와의 모든 통신에서 서버의 확인 요구를 충족 할 수 있는지 확인하는 방법을 나타냅니다. 특정 권한이 있는지 여부에 대한 판단은 포함되지 않습니다.
로그인의 경우 주로 사용자의 사용자 이름 및 비밀번호 입력을 수락하고 확인을 위해 서버에 제출하고 확인 응답 처리 및 브라우저 측에서 인증 데이터를 빌드해야합니다 .
신원 인증을 구현하는 두 가지 방법
현재 ID 인증을 구현하기위한 두 가지 주요 범주의 방법이 있습니다.
쿠키
기존 브라우저 웹 페이지는 쿠키를 사용하여 신원을 확인합니다. 실제로 브라우저의 응용 프로그램 계층에서는 기본적으로 신원 확인에 대해 걱정할 필요가 없습니다. 쿠키 설정은 서버에서 완성됩니다. 요청을 제출할 때 브라우저는 해당 쿠키 정보를 자동으로 첨부합니다. 따라서 JavaScript 코드에서는 이에 대한 특수 코드를 작성할 필요가 없습니다. 그러나 요청할 때마다 모든 쿠키 데이터를 가져올 것입니다.
CDN을 적용하고 모바일 장치가 점진적으로 증가함에 따라 쿠키는 복잡한 다중 도메인 인증 요구를 충족시킬 수 없습니다.
열쇠
실제로, 키 기반 인증은 최근에 나타 났을뿐만 아니라 쿠키의 역사보다 더 길어졌습니다. 브라우저가 서버를 요청하면 요청의 헤더와 같은 특정 방식으로 요청의 키를 첨부합니다. 이를 위해서는 특별 클라이언트 코드가 관리를 위해 작성되어야합니다.
최근에 떠오르는 JSON 기반 웹 키 （JSON Web Token） 표준은 키를 사용한 일반적인 인증입니다.
웹 응용 프로그램에서 API를 구성하는 경우 키 메소드를 사용하는 데 우선 순위를 부여해야합니다.
프로세스 로그인
로그인은 신원 확인의 첫 단계입니다. 로그인 만 해당 신분 검증 데이터를 구성 할 수 있습니다.
별도의 로그인 페이지를 사용해야합니까?
로그인 페이지를 처리하는 두 가지 방법이 있습니다.
로그인이 완료된 후 별도의 로그인 페이지가 단일 페이지 응용 프로그램으로 이동합니다. 이를 통해 단일 페이지 애플리케이션의 리소스에 대한 액세스 제어는 로그인이 아닌 사용자가 액세스하는 것을 방지 할 수 있으며 배경 또는 관리 도구의 응용 프로그램 시나리오에 적합합니다. 그러나 실제로 단일 페이지 응용 프로그램의 사용자 경험을 줄입니다.
단일 페이지 응용 프로그램 내에서 로그인을 실행합니다 . 단일 페이지 응용 프로그램의 디자인 개념과 더 일치하며 악의적 인 사람들이 항상 단일 페이지 응용 프로그램의 프론트 엔드 코드를 얻을 수 있기 때문에 인기있는 제품 시나리오에 더 적합합니다.
별도의 로그인 페이지
일반적으로 별도의 로그인 페이지를 사용하는 목적은 로그인 후 점프 된 페이지가 익명 사용자가 액세스하지 못하도록 보호하는 것입니다. 따라서 로그인 페이지에서 양식이 구성되고 기존의 칭찬 제출 방법 (비 Ajax)이 직접 사용됩니다. 백엔드가 사용자 이름과 비밀번호를 성공적으로 확인한 후 로그인 후 단면 응용 프로그램 페이지의 HTML이 출력됩니다.
이 경우 출력 HTML에 인증 정보를 직접 배치 할 수 있습니다. 예를 들어 Jade를 사용하여 다음과 같은 페이지를 구성 할 수 있습니다.
<!-dashboard.jade-> doctype htmlhtmlhtml Head Link (rel = "Stylesheet", href = "/assets/app.e1c2c6ea9350869264da10de7999dced1.css") 바디 스크립트. window.token =! {json.stringify (Token)}; Div.Md-Padding (UI-View) 스크립트 (SRC = "/Assets/App.84B1E53DF1B4B23171DA.JS")사용자 이름과 비밀번호 확인이 성공한 후에 백엔드는 다음 방법을 사용하여 HTML을 렌더링하고 출력 할 수 있습니다.
return res.render ( '대시 보드', {Token : Token});Angular Application이 시작되면 인증과 통신 할 수 있습니다. 또한 성공적으로 로그인 한 사용자만이 페이지를 입력 할 수 있습니다.
단일 페이지 앱에 로그인하는 조직
다중 뷰 각도 응용의 경우 일반적으로 라우팅이 사용됩니다. 페이지에는 일반적으로 고정 된 사이드 바 메뉴 또는 상단 탐색 메뉴가 있으며 텍스트 영역은 라우팅 모듈에 의해 제어됩니다.
다음 샘플 코드는 각도 자료를 사용하여 페이지를 정리하고 라우팅 모듈은 UI-Router를 사용합니다. 응용 프로그램이 열리면 특수로드 애니메이션이 있습니다. 로드가 완료된 후 표시된 페이지는 AppController 컨트롤러에서 사용됩니다. 로그인하지 않은 사용자의 경우 로그인 양식이 표시됩니다. 로그인이 완료된 후 페이지는 세 부분으로 나뉩니다. 하나는 빵 부스러기 내비게이션이고 , 두 번째는 사이드 바 메뉴이고 , 다른 하나는 경로 컨트롤의 주요 부분 입니다.
코드는 다음과 같습니다.
<body ng-app = "app"layout = "row"> <div id = "로드"> <!-페이지로드 프롬프트-> </div> <div flex 레이아웃 = "row"ng-cloak ng-controller = "appcontroller"ng-init = "load ()"> <div ng-if = "! Isuserauth", ng-controller ", ng-controller", ng-controller. <!-loginform-> </div> <div ng-if = "isuserauth"flex 레이아웃 = "row"> <md-sidenav flex = "15"md-is-locked-open = "true"> <!-사이드 바 메뉴-> </md-sidenav> <md-content flex layout = "culign"> <md-toolbar> <! </md-toolbar> <md-content> <!-라우팅-> <div ui-view> </div> </md-content> </md-content> </div> </div> </body>
애니메이션을로드하려면 AppController 외부에 있으며 AppController 코드에 숨겨 질 수 있습니다. 이로 인해 모든 CSS/JavaScript가로드 된 후 로딩의 목적이 사라집니다.
AppController 에는 변수가 있습니다 isUserAuth 초기화되면 false 입니다. 로컬로 저장된 세션 정보가 유효하거나 로그인이 완료된 후이 값은 ture 로 설정됩니다. ng-if 의 제어로 인해 로그인 양식을 숨기고 응용 프로그램 내용을 표시하는 목적을 달성 할 수 있습니다. 여기서 ng-show/ng-hide 대신 NG- ng-if 사용 함으로써만, 전자는 DOM 요소를 진정으로 삭제하고 추가하는 반면, 후자는 DOM 요소의 CSS 속성 만 수정한다는 점에 유의해야합니다. 이것은 매우 중요합니다. 이런 식으로 만 로그인 한 후 단일 페이지 응용 프로그램의 컨텐츠가로드되어 현재 경로의 컨트롤러 코드가 로그인하기 전에 직접 실행되는 것을 방지 할 수 있습니다.
고객이 암호를 암호화하는 이유는 무엇입니까?
사용자 이름과 비밀번호를 기반으로 이상적인 로그인 프로세스는 다음과 같습니다.
1. 브라우저 측은 사용자가 입력 한 암호를 얻고 MD5와 같은 해싱 알고리즘을 사용하여 md5(username + md5(md5(password))) 와 같은 고정 된 길이의 새 비밀번호를 생성 한 다음 Backing hash 값 및 사용자 이름을 백엔드에 부착합니다.
2. 백엔드는 사용자 이름을 기준으로 해당 소금을 얻고 사용자 이름과 암호 해시 값을 사용하고 암호 텍스트를 계산하며 사용자 이름과 비밀번호를 기반으로 데이터베이스를 검색합니다.
3. 쿼리가 성공하면 키를 생성하고 브라우저로 반환하고 4 단계를 수행하십시오.
4. 백엔드는 새로운 소금을 생성하고 새로운 소금과 브라우저에서 제출 한 암호 해시 값을 기반으로 새로운 암호 텍스트를 생성합니다. 데이터베이스에서 SALT 및 CIPHERTEXT를 업데이트하십시오
아마도 80%의 사람들이 로그인이 왜 그렇게 복잡한 지 이해할 수 없을 것입니다. 이것은 명확하게 설명하기 위해 특별한 기사가 필요할 수 있습니다. 여기서 먼저 브라우저가 암호를 해시하는 이유를 설명하고 그 이유는 다음과 같습니다.
1. 주요 레코드를 수행 하여만 사용자의 원래 비밀번호를 얻을 수 있는지 확인하기 위해 소스로부터 사용자의 비밀번호를 보호하십시오.
2. 네트워크를 도청하고 HTTPS를 사용하지 않더라도 도난당한 암호는 해싱 후에 만이 서버의 사용자 데이터에 최대 영향을 줄 수 있으며 동일한 암호를 사용하는 다른 웹 사이트에 영향을 미치지 않습니다.
3. 서버의 소유자조차도 사용자의 원래 비밀번호를 얻을 수 없습니다.
이 접근법은 사용자에게 가장 큰 위험을 초래하고 현재 응용 프로그램의 데이터를 도난당했습니다. 손실 범위는 확장되지 않으며 CSDN이나 다른 스트림에는 아무런 문제가 없습니다.
성공적인 알림을 로그인하십시오
일부 응용 프로그램의 경우 모든 페이지에 사용자가 로그인 해야하는 것은 아닙니다. 특정 작업을 수행 할 때만 로그인해야 할 수도 있습니다. 이 경우 로그인 한 후 전체 응용 프로그램에 알려야합니다. 이를 통해 방송 기능을 사용할 수 있습니다.
간단한 코드는 다음과 같습니다.
Angular .Module ( 'app') .controller ( 'logincontroller', [ '$ rootscope', logincontroller]); function logincontroller ($ rootscope) {// function lall afrloginsuccess () {$ rootscope. $ broadcast ( 'user.login.success'); }}다른 컨트롤러에서는이 브로드 캐스트를 듣고 로그인이 성공한 후에 수행 해야하는 작업을 수행 할 수 있으며, 예를 들어 목록 또는 세부 사항을 얻습니다.
$ scope. $ on ( 'user.login.success', 함수 (핸들, 데이터) {// processing});신원 인증 정보
성공적으로 로그인 한 후 서버는 키를 반환하고 후속 API 요청은 키를 가져와야하며, 요청에 의해 반환 된 응답도 신원 정보의 무효성에 대한 오류인지 확인해야합니다. 이 일련의 작업은 매우 번거롭고 자동으로 완료해야합니다.
구하다
키를 저장하는 다음과 같은 방법이 있습니다.
1. 쿠키 : 앞에서 언급했듯이 권장되지 않습니다. 동시에 최대 한계는 4K입니다.
2.sessionStorage : 탭 페이지가 유효합니다. 닫히거나 새 탭 페이지가 열리면 SessionStorage를 공유 할 수 없습니다.
3. localstorage : 이상적인 저장 방법. 브라우저 데이터가 정리되지 않으면 LocalStorage에 저장된 데이터는 항상 존재합니다.
4. Angular Singleton Service : 응용 프로그램에 저장되면 새로 고침 후 데이터가 손실되며 물론 탭 페이지간에 공유 할 수 없습니다.
더 나은 접근 방식은 인증 정보가 LocalStorage에 저장되지만 응용 프로그램이 시작될 때 Angular의 싱글 톤 서비스로 초기화된다는 것입니다.
요청에 인증 정보를 추가하십시오
신원 인증 정보의 목적은 서버에 대한 ID를 나타내고 데이터를 얻는 것입니다. 따라서 요청에 추가 인증 정보가 필요합니다.
일반적인 응용 프로그램에서 인증 정보는 요청의 헤더에 배치됩니다. 각 요청에서 헤더를 하나씩 설정하면 너무 시간이 많이 걸리고 힘들 것입니다. Angular의 $httpProvider 모든 요청과 응답의 통합 처리를 달성 할 수있는 인터셉터 interceptors 제공합니다.
인터셉터를 추가하는 방법은 다음과 같습니다.
Angular .Module ( 'app') .config ([ '$ httpprovider', function ($ httpprovider) {$ httpprovider.interceptors.push (httpinterceptor);}]); HttpInterceptor 의 정의는 다음과 같습니다.
Angular .Module ( 'app') .factory ( 'httpinterceptor', [ '$ q', httpinterceptor]); 함수 httpinterceptor ($ q) {return {// 요청이 발행되기 전에 다양한 인증 정보 요청을 추가하는 데 사용될 수 있습니다 : function (suctig) {if (localStorage.token); } 반환 구성; }, // 요청이 발행되는 동안 오류가 발생했습니다. }, // 응답 응답 : function (res) {return res; }, // 백엔드가 응답을 반환 할 때 반환 된 응답 오류는 비 200의 HTTP 상태 코드가 설정됩니다. }};}인터셉터는 요청에서 반환 응답으로의 전체 수명주기 처리를 제공하며, 일반적으로 다음을 수행하는 데 사용할 수 있습니다.
1. 인증 정보 추가와 같은 균일하게 발행 된 요청에 데이터 추가
2. 요청이 발행 된시에 오류를 포함하여 통합 오류 처리 (예 : 브라우저 측의 네트워크가 연결되지 않음) 및 응답이 반환 될 때의 오류
3. 일부 데이터 캐시 등과 같은 통합 응답 처리 등
4. 요청 진행률 표시 줄을 표시하십시오
위의 예제 코드에서 localStorage 에 값 token 포함 된 경우 각 요청의 헤드에 token 값이 추가됩니다.
실패 및 취급
일반적으로 백엔드는 token 검증이 실패 할 때 응답 HTTP 상태 코드를 401로 설정하여 인터셉터 responseError 에서 균일하게 처리 할 수 있도록해야합니다.
responseRror : function (err) {if (-1 === err.status) {// 원격 서버는 응답하지 않습니다} else if (401 === err.status) {// 401 오류는 일반적으로 인증 실패에 사용됩니다. 인증이 실패 할 때 백엔드에 의해 발생 된 오류에 따라 다릅니다.요약
실제로 서버에서 반환 한 상태 코드가 200이 아닌 responseError 호출됩니다. 여기서 오류는 균일하게 처리되어 표시 될 수 있습니다.
위의 내용은 각도 개발 응용 프로그램의 로그인 및 신원 확인과 관련이 있습니다. 모든 사람이 앵글을 배우는 것이 도움이되기를 바랍니다.