✏️ 2022-12-28 Today I Learn

[회고] 221228 : Swagger Page 권한 허용하기

스프링 시큐리티를 기존 프로젝트에 적용하는 과정에서, 스웨거 문서에 접속을 시도할 때 403에러가 발생하는 이슈가 발생했다. 해당 이슈를 해결하기 위해서 시큐리티 설정 측에서 스웨거 페이지에 대한 접근을 허가했다. 하지만.. 지속적으로 에러가 발생하여 로그를 보니, 토큰을 인가하는 로직이 잘못된 부분이 있었다. 그런데, 이상한 점이 나는 분명히 permitAll 처리를 해놓았는데, 왜 시큐리티 필터 체인로직을 거치는지 이해가 가지 않았다.

authenticated() 를 붙힌로직만 시큐리티 필터 체인로직을 거친다고 생각했는데, 잘못된 접근이었다. authenticated() 를 api 에 붙히는 것과 시큐리티 필터는 별개의 것이다. 시큐리티 필터는 설정시 무조건 거쳐야 했고, authenticated()를 붙힌 api역시 시큐리티 필터를 거치되, 토큰을 검증함으로서 로그인 여부를 결정하여 결과를 반환해주는 동작을 하게 된 것이었다.

로그인이 되었다면 SecurityContext 내부에 Principle이 정상적으로 셋팅되었을 것이고, 그것에 따라 로그인 여부를 판단하는 것 같다. 참고로 스웨거는 다양한 주소를 통해 페이지를 렌더링하는데, 아래는 시큐리티 설정 시 허용해야 할 스웨거 주소들의 목록이다.

    private static final String[] PERMIT_URL_ARRAY = {
            /* swagger v2 */
            "/v2/api-docs",
            "/swagger-resources",
            "/swagger-resources/**",
            "/configuration/ui",
            "/configuration/security",
            "/swagger-ui.html",
            "/webjars/**",
            /* swagger v3 */
            "/v3/api-docs/**",
            "/swagger-ui/**"
    };

이 삽질을 통해서, 시큐리티 필터체인이 어떤시점에 동작하는지 이해 할 수 있었고, 설정들을 다양하게 조합하여 어떻게 실행되는지 직접 볼 수 있었다.

[TodayKeywords] 오늘 공부한 키워드

• UserDetails : SecurityContext 에 담기는 User 정보를 가져오는 공간이다.
• hasRole vs @Secured : config 를 통해 설정하는 방법과, annotation을 통해 설정하는 방식의 차이이다. 둘의 기능은 같지만, hasRole은 접근권한을 config에서 한번에 관리 할 수 있고, @Secured는 controller에 직접 명시하여 관리 할 수 있다는 차이점이 있다.

[NextKeyworks] Study Queue

• HTTPS
• SOLID
• loop label
• CSV
• 파일입출력
• UML
• UTC
• epoch time / Instant time
• MVC
• URL ClassLoader
• Secure ClassLoader
• JNI
• GC
• HOF
• 자바 해시코드(hashCode)
• OSI 7 계층
• PCB
• 스프링 설계철학
• RESTful
• 준 영속성
• 지연로딩
• 프록시객체
• jpa - mybatis 의 차이
• orm - mapper 의 차이
• 쿠키/세션/로컬 스토리지
• HttpMessageConverter
• 서블릿
• ACID