이제 웹 애플리케이션 내에
인가 관련
변경이 필요한 때 입니다
requestMatchers의 도움을 받아
우리가 보안 구성을 만든
위치를 살펴보아야 합니다
보다시피 ProjectSecurityConfig 안에서
SecurityFilterChain 빈을 생성하려는
메소드 내부가 있습니다
우리는 이러한 requestMatchers의 도움을 통해
Spring Security의 요구 사항들을 정의했습니다
이제 이 구성들을 가지고
로그인 한 어느 유저든 웹 애플리케이션 내의
어느 API 또는 UI페이지에 손쉽게 접근할 수 있습니다
그러나 이제 상황을 바꿔보려고 합니다
인가를 강제하고 싶습니다
그래서 여기에 몇 줄의 코드를 붙여 넣어서
함께 논의해보고자 합니다
여기서 볼 수 있듯이 제가 이 몇 줄의 코드를 붙여 넣었고
이 줄들은 따로 설명할 필요는 없습니다
우선 requestMatchers의 도움을 받아
저는 제가 인가의 규칙을 강제하고 싶은 API가
어디인지 말하고자 합니다
계정의 경우
권한 VIEWACCOUNT의 도움을 받아
권한 규칙을 강제하고자 하므로
hasAuthority() 메소드를 사용하고 있습니다
반면 MYBALANCE에서 저의 요구사항은
VIEWACCOUNT 또는 VIEWBALANCE 권한을 가진
엔드 유저를 허용하는 것입니다
이것이 바로 hasAnyAuthority() 메소드를 사용하는 이유입니다
그리고 비슷하게 MYLOANS, MYCARDS 와 같은 다른 API paths 에서도
저는 권한 세부 정보와 함께
hasAuthority() 메소드를 호출하고 있습니다
여기서는 정규 표현식 패턴을 활용할
복잡한 요구 사항이 없기 때문에
access 메소드를 사용하지 않고 있습니다
여러 API URL이 동일한 권한 요구 사항을
가지는 시나리오가 있다면
requestMatchers 메소드에
그 모든 API를 쉼표로 구분하여 나열할 수 있습니다
이해가 되었길 바랍니다
이제 우리가 이미 MYACCOUNT, MYBALANCE,
MYLOANS 그리고 MYCARDS에 대해 정의를 살펴보았기 때문에 다시 언급할 필요가 없습니다
따라서 여기 모든 API URLs 를 지우겠습니다
그리고 이를 통해 슬래시(/) 사용자에 대해
어떤 인가도 강제하고 싶지 않음을 알리고 있습니다
로그인한 유저는 누구든
제 유저 API에 접근할 수 있어야 합니다
이것이 authenticated 메소드만 호출한 이유입니다
그리고 permitAll에 관한 부분은
이러한 공개 API URL과 관련된 내용을 변경할 필요가 없습니다
이러한 변경사항으로 우리가 원하는 결과를 얻을 것으로 기대합니다
이제 변경 사항을 저장하고 빌드를 진행해 보겠습니다
빌드가 완료되면
웹 애플리케이션을 시작합니다
똑같이 EasyBankBackendApplication으로
이동하겠습니다
여기서 웹 애플리케이션을 디버그 모드로 시작하려고 합니다
이제 저의 웹 애플리케이션은 성공적으로 시작되었습니다
다음 단계로 UI 애플리케이션으로 가서
Happy 자격 증명으로 로그인을 시도해봅니다
왜냐하면 유저 Happy는 데이터베이스 내의
구성되어있는 모든 권한을 가지고 있기 때문입니다
따라서 그는 문제없이
모든 API에 접근할 수 있어야 합니다
자 여기서 happy@example.com
12345 그리고 로그인 버튼을 눌러 진행합니다
먼저 Account를 확인합니다
여기서 성공적인 응답을 얻을 수 있습니다
다음 Balance로 갑니다
여기서도 제대로 작동됩니다
다음 Loans로 갑니다
이것 또한 완벽히 작동하며 Cards도 동일합니다
검증할 수 있고 이것도 잘 작동하는 것 같습니다
이제 우리는 몇 가지의 부정적인 시나리오를 가지고 테스트를 진행해볼 수 있습니다
이와 관련하여 할 수 있는 것은
현재 myCards API에 대해서는
VIEWCARDS 권한이 있는 것으로 알려져 있습니다
이 권한 이름을 VIEWCARDDETAILS로 변경해보겠습니다
새로운 권한 이름의 경우
데이터베이스 내의 엔드 유저인 Happy 를 위해
구성되어 있는 것은 아무것도 없습니다
그래서 엔드 유저가 myCards API에 액세스하려고 하면
성공적인 응답 대신 에러를 받아야합니다
이게 여기서의 플랜입니다
이 변경사항들을 저장하고 여기서 빌드를 하고
로그아웃한 다음 다시 로그인 해보겠습니다
이제 저는 저의 자격 증명으로 들어갈 겁니다
이번에는 우선
Balance와 같은 다른 APIs를 확인합니다
작동합니다
이제 Cards를 클릭하기 전에
우리가 받는 금지된 에러를 확인하기 위해
개발자 콘솔을 열 것입니다
여기 콘솔을 먼저 깨끗하게 지워봅시다
Cards 탭을 누르면
금지된 에러인
403 에러를 볼 수 있습니다
이로써 모든 권한 변경이
완벽하게 작동하고 있습니다
우리는 여기서 하나의 변경사항을 되돌릴 수 있습니다
이로써 우리는 VIEWCARDS라는
이전 권한으로 돌아갑니다
이 변경사항들을 저장합니다
그리고 여기서 빌드를 합니다
로컬 시스템 내에서
Angular UI 애플리케이션을 사용하지 않거나
설정하지 않은 경우에도
직접 REST API를 호출하여
이러한 변경 사항을 확인할 수 있습니다
이를 위해 Chrome 브라우저 내에서
새 탭을 열고
myAccount REST API 경로를 호출하고자 합니다
그런데 직접적으로 호출을 시도하기 이전에
여러분이 controller 클래스, myREST API 서비스를 확인하면
쿼리 매개변수를 예상할 수 있습니다
쿼리 매개변수 이름은 'id'이며
Happy 엔드 유저의 경우 고객 ID 값은 1입니다
그래서 이 값을 주는 것입니다
따라서 이것에 접근하려고 하면
우선 저의 Spring Security는 로그인 페이지를 보여줄 것입니다
여기서 happy@example.com과 12345를 입력합니다
로그인을 하자마자
customerId, accountNumber
accountType, branchAddress, 그리고 createdDate 같은
완벽한 JSON 응답을 받는 것을 볼 수 있습니다
비밀번호와 엔드 유저의 권한을
가져오지 못하는 이유는 customer 엔터티 클래스 내에서
JsonIgnore 주석 및
다른 유형의 주석을 사용하고 있기 때문입니다
비밀번호와 권한은 민감한 정보인 만큼
이 세부정보들을 UI로 보내지 않습니다
굉장히 비슷하게 myLoans도 확인할 수 있습니다
이렇게 하면 사용자가 가지고 있는 모든 대출이 나열되며
myCards도 테스트할 수 있습니다
이것은 카드의 세부 정보입니다
이 JSON 응답을 사용하여 클라이언트 애플리케이션은
일부 CSS를 적용하여 HTML 형식으로
엔드 유저에게 표시하려고 하며
브라우저 내에서는 JSONView라는
플러그인을 사용합니다
따라서 언제든 이 Chrome 브라우저 내에 이것을 설치할 시
받는 모든 JSON 응답은
형식이 지정되어
이와 같이 표시됩니다
그렇지 않으면 이해하기 어려울 정도로 번거로운
한 줄을 받게 될 것입니다
만약 관심이 있다면
Chrome 브라우저에도 이 플러그인을 설치할 수 있습니다
이렇게 웹 애플리케이션 내의 권한들의 도움을 받아
인가를 성공적으로 실행했습니다
다음 강의에서는
Spring Security 내에서 '역할(roles)'이 무엇이며
그동안 논의한 '권한(authorities)'과
어떻게 다른지 살펴보겠습니다
감사합니다 다음 영상에서 뵙겠습니다
수고하셨습니다