이전 수업에서는
@PreAuthorize 주석이 활용되는 모습을 관찰했습니다
@PreAuthorize 주석을 이용하여
권한을 강제하는 것을 보았습니다
이제 이번 수업에서는
@PostAuthorize 주석 활용하여
Java 메소드 위에 권한을 강제하는 것을 살펴 보도록 하겠습니다
가장 먼저 해야 할 일은
해당 @PreAuthorize 주석에
변경 사항에 대한 코멘트를 작성해 줍니다
그리고 이번에는 주석 속 변경을
Loans의 컨트롤러 클래스에서 진행하겠습니다
컨트롤러 패키지 아래에
LoansController 클래스를 열겠습니다
해당 LoansController 안에는
getLoanDetails라는 메소드가 있는데
이는 대출에 대한 정보를 엔드 유저에게
리턴하는 것을 담당합니다
이 메소드 위에
@PostAuthorize 주석을 언급하겠습니다
그리고 해당 주석에는
hasRole을 이용하여 권한 규칙도
정의합니다
여기서 역할(role)의 이름은
다시 한번 ROOT로 사용하겠습니다
이는 권한 규칙과 관계 없이
메소드가 호출될 것이라는 의미입니다
하지만 해당 값들을 엔드 유저에게 다시 전송하려 할 때
Spring Security가 이 사람은
ROOT라는 이름의 역할이 없음을 깨닫고
출력을 전달하지 않는 것입니다
이 내용을 증명하기 위해 우선 bill을 먼저 하겠습니다
그리고 이 메소드 안에 우선 중단점을 넣어뒀습니다
이는 메소드 호출은 진행되지만
결과는 엔드 유저에게 다시 전송되지 않음을 보이기 위해서 입니다
이제 여기 UI 애플리케이션으로 들어왔습니다
개발자 콘솔을 열어주고
현재 있는 콘솔을 전부 치우겠습니다
이제 Loans에 클릭을 하겠습니다
메소드가 호출 되었고
요청을 처리하지만
중단점에서 멈췄음을 볼 수 있습니다
해당 내용을 줄 별로 이해해 봅시다
여기 Loans의 사이즈가 4이고
우리는 그걸 다시 보내려하고 있습니다
이로 인해 모든 비즈니스 로직은 완료 되었지만
뒤에서 보면
Spring Security가 해당 값을 다시 전송하지 않을 것입니다
대신 403 에러를 띄우게 됩니다
여기서 일어난 일이고
그렇기 때문에 해당 페이지에서 데이터가 없는 것입니다
왜냐하면 엔드 유저가 Loans에 대한 정보를 받은 바가 없기 때문입니다
이것이 메소드 레벨 보안의 힘입니다
이해가 되었길 바랍니다
웹 애플리케이션에서 메소드 레벨 보안은
인증, 인가와 함께
꼭 활용해 보시기 바랍니다
이제 이 ROOT를 USER로 변경합니다
그러면 엔드 유저가 Loans 정보를 받았는지
검증해 볼 수 있습니다
이번에는 분명 Loans에 대한 모든 정보를
받았을 것입니다
이제 유저의 역할이 주어졌기에
정당한 유저가 되었고
데이터베이스 안으로도 접근이 허용됐기 때문입니다
따라서 이번에는 돌아가서
다시 열어보면
실행이 다시 멈췄습니다
이 중단점를 해제하겠습니다
여기 UI 안에
백엔드에서 UI로 보낸
4개의 대출 정보를 모두 확인할 수 있습니다
그리고 이제 @PreAuthorize 주석의 도움으로
메소드 호출을 어떻게 제어하는지
그리고 어떤 Java 메소드든지
@PostAuthorize 주석을
사용하여
엔드 유저에게 반환할 리턴 객체와
결과를 제어하는 방법을
아주 명확히 이해하셨기를 바랍니다
해당 메소드는 어떤 레이어든 관계 없으며
controller layer
service layer 또는 repository layer에도 있을 수 있습니다
본인의 웹 애플리케이션 속에
얼마든지 해당 주석들을 활용할 수 있습니다
그럼 다음 강의 때 뵙겠습니다
감사합니다