HttpSecurity 의permitAll()을 사용
permitAll()은 어떠한 권한이든 해당 API에 접근할 수 있게는 한다.
하지만 모든 필터를 거치치않고 통과 시킨다는 의미는 아니다!
따라서 필터 내에서 거치지 exception을 설정하지 않는지 확인하자.
이를테면 직접 만든 필터에 경우 exception을 설정하는 경우가 많다.
...
...
// 이전 코드 생략
if (header == null || !header.startsWith("Bearer ")) {
throw new IllegalArgumentException("올바른 header 형식이 아닙니다.");
}위 코드는 custom 하게 만든 필터 중 코드의 일부분이다. 이 필터는 사용자의 jwt 필터를 꺼내어서 확인하는 필터가 인데 permitALL()에 경우 jwt가 아직 발급되지 않는 페이지일 경우가 많다.
따라서 jwt가 발급되지 않은 상태이므로 header가 null 이므로 exception을 던지며 코드가 종료된다.
따라서 이경우 해결할 수 있는 방법으로는 두가지가 있다 .
- exception을 던지지 않고 그냥 다음 필터로 보낸다.
- 다른 기능을 추가한다.
1번에 경우 보안문제와 어디서 오류가 발생했는지 파악하기 어렵다는 치명적인 결함이 있으므로
다른 기능을 사용했다.
@Override
protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
String path = request.getRequestURI();
// 특정 경로를 무시하도록 설정
return path.startsWith("/auth") ;
}
permitAll()으로 필터까지 거치지 않게 하고 싶기에 위 코드를 추가하여 문제를 해결할 수 있었다.
HttpSecurity의 hasRole()과 hasAuthority()
permitAll()과 반대로 권한이 있는 유저만 페이지를 접근할 수 있도록 할때 has~() 메서드를 사용한다.
hasRole에 인자로 담기는 값은 자동으로 접두사가 "ROLE_"이 붙는다.
반면에 hasAuthority는 인자 그대로 값을 확인한다.
jwt를 사용하여 해당 유저의 권한을 넘기는 경우 claim 값 설정시 주의해야하는 부분이다.
권한을 체크할때 SecurityContextHolder 내부에 Authentication 값을 가져와서 권한을 확인할때
두개의 용도를 정확히 모르고 사용하면 엉뚱한 값으로 매치할수 있다.
자세한 내용은 Security를 시리즈로 정리할때 담아보려고 한다.
