Spring

Bean Validation Annotation 종류

Bean Validation이란? 특정 구현체가 아닌 Bean Validation 2.0(JSR-380)이라는 기술 표준으로 여러 검증 애노테이션과 여러 인터페이스의 모음이다. javax.validation 패키지였지만 현재는 jakarta.validation 패키지이다. Jakarta Bean Validation 2.0 - Java 8 이상 Jakarta Bean Validation 3.0 - Java 11 이상 Spring Boot 3.0.0 M1 릴리스 노트 에서 Spring Boot 2.X는 Jakarta EE를 지원하지 않지만 Spring Boot 3.X에서는 지원이 제공된다. Spring Boot 2.X의 경우 javax. Spring Boot 3.X의 경우 jakarta. 를 사용해야 한다...

Jackson 직렬화 무시 어노테이션 사용 - @JsonIgnore @JsonIgnoreProperties @JsonIgnoreType

Jackson 직렬화 무시 어노테이션 사용 - @JsonIgnore @JsonIgnoreProperties @JsonIgnoreType 직렬화와 역직렬화 직렬화 -직렬화는 객체를 파일의 형태 등으로 저장하거나, 통신하기 쉬운 포맷으로 변환하는 과정 객체의 직렬화는 객체의 내용을 바이트 단위로 변환하여 파일 또는 네트워크를 통해서 스트림(송수신)이 가능하도록 하는 것을 의미한다. 역직렬화 - 특정 포맷으로 직렬화된 데이터는 역직렬화라는 과정을 통해 다시 객체로 변환 직렬화된 파일 등을 역으로 직렬화하여 다시 객체의 형태로 만드는 것을 의미한다. 저장된 파일을 읽거나 전송된 스트림 데이터를 읽어 원래 객체의 형태로 복원한다. @JsonIgnore 필드 레벨에서 무시 될 수있는 속성을 표시하는 데 사용된다. ..

Cannot call sendError() after the response has been committed - 순환 참조 문제 With JPA Entity

Cannot call sendError() after the response has been committed - 순환 참조 문제 이 문제는 Jackson을 이용한 직렬화/ 역직렬화 과정에서 발생한다. 일반적으로 JPA Entity에서 양방향 관계를 맺었을 떄, 컨트롤러의 API 응답결과로 Entity를 반환하면 Jackson은 응답 결과 객체의 필드를 바탕으로 JSON을 만든다. 이 때 양방향 관계로 서로를 참조하고 있으니 무한하게 재귀적으로 참조를 하다가 StackOverFlow가 발생하여 직렬화를 못하고 에러를 발생시키는 문제이다. 응답이 커밋된 후 sendError()를 호출할 수 없다. Infinite Recursion - 무한 재귀 원인 먼저 Jackson 무한 재귀 문제 원인을 살펴보자 간단..

SpringBoot AutoConfiguration 제외 방법

SpringBoot에서 사용되는 각 Spring 의존성마다 XXXX AutoConfiguration이 있다 이 클래스들을 제외시키면된다 예를들어 yml이나 properties로부터 DataSource를 구성해주는 DataSourceAutoConfiguration이라면 다음과 같이 두 가지의 제외 방법이 있다. 1. 어노테이션기반 AutoConfigruation 제외 @SpringBootApplication(exclude={DataSourceAutoConfiguration.class}) DataSourceAutoConfigration 제외 다른 빈을 자동 구성하는 데 영향을 미치지 않으며 Spring Boot의 DataSourceAutoConfigruation을 비활성화할 수 있다. 2. 구성 설정 파일(..

HeaderWriterFilter - 응답헤더에 보안 관련 헤더 추가하는 필터

HeaderWriterFilter - 응답헤더에 보안 관련 헤더 추가하는 필터 응답 헤더에 보안 관련 헤더를 추가해준다. 기본적으로 생성되는 필터이며 앞단부분에 위치하는 필터이다 내부적으로 HeaderWrite 인터페이스를 List로 가지고 있다. private final List headerWriters; 기본적으로 5개의 header writer 적용 XContentTypeOptionsHeaderWriter : MIME타입 스니핑 방어 XXssProtectionHeaderWriter : 브라우저에 내장된 XSS 필터 적용 CacheControlHeadersWriter : 캐시 히스토리 취약점 방어 XFrameOptionsHeaderWriter : HTML삽입 취약점 방어로 iframe, object ..

AccessDecisionVoter 커스텀

요구사항 "/admin" URL 접근에 대한 접근 권한 검사 Admin 사용자의 로그인 아이디 끝 숫자가 홀수 인 경우 접근 허용 URL이 "/admin" 이 아닌 경우 접근을 승인함 기본 expressionHandler를 사용 accessDecisionManager 인터페이스 구현체 중 UnanimousBased를 사용 SecurityConfig 구현 - HttpSecurity, AccessDecisionManager 설정 @Configuration @EnableWebSecurity public class SecurityConfig { public AccessDecisionManager accessDecisionManager() { List

ExceptionTranslationFilter - 예외 전환 필터

FilterSecurityInterceptor 바로 위에 위치하며, FilterSecurityInterceptor 실행 중 발생할 수 있는 예외(AccessDeniedException과 AuthenticationException을)를 잡고 처리한다 FilterSecurityInterceptor는 FilterChainProxy에서 필터 가장 마지막에 위치한다. 필터 체인에서 발생하는 AccessDeniedException과 AuthenticationException을 처리하는 필터 처리할 수 없는 예외는 rethrow 하여 그냥 앞으로 던져버린다. FilterSecurityInterceptor 가 AccessDecisionManager 를 통해 AuthenticationException 혹은, Access..

AccessDecisionManager, AccessDecisionVoter - 인가 결정 심의자

AccessDecisionManager는 AbstractSecurityInterceptor에서 호출하며, 최종적인 접근 제어를 결정한다. FilterSecurityInterceptor (AbstractSecurityInterceptor) AccessDecisionManager는 세 가지 메소드가 있다: void decide(Authentication authentication, Object secureObject, Collection attrs) throws AccessDeniedException; boolean supports(ConfigAttribute attribute); boolean supports(Class clazz); decide() : 권한을 결정하기 위해 필요한 모든 정보를 건내 받는다..

Security 인가 처리 개념 및 과정 (Authorization), AccessDecisionManager

인가(Authorization) : 인증 된 사용자가 특정 자원에 접근하고자 할 때 접근 할 자격이 되는지 증명하는 것 사용자가 특정 자원에 접근하고자 요청(Request)을 하면 그 사용자가 인증을 받았는지 확인한다. 그림상 사용자의 자격(권한)은 Manager이다 인증을 받은 사용자라면 해당 사용자의 자격(권한)이 해당 자원에 접근할 자격이 되는지 확인한다. 일반적으로, 인가를 처리하는 Spring Seucirty FilterSecurityInterceptor에 도착하면 인증이 완료되어있다. 익명 사용자도 인증이 완료된 것으로 간주하며, ROLE_ANONYMOUS 권한을 갖음 인가 처리(Authorization) 에서 사용자의 권한(자격) Manager이기 때문에 User Section, Manage..

FilterSecurityInterceptor - 인가(Authorization) 처리 필터

필터 체인 상에서 가장 마지막에 위치하며, 사용자가 갖고 있는 권한과 리소스에서 요구하는 권한을 취합하여 접근을 허용할지 결정한다. 실질적으로 접근 허용 여부 판단은 FilterSecurityInterceptor 내부 프로세스에서 AccessDecisionManager 인터페이스 구현체에서 이루어짐 해당 필터가 호출되는 시점에서 사용자는 이미 인증이 완료되고, Authentication 인터페이스의 getAuthorities() 메소드를 통해 인증된 사용자의 권한 목록을 가져올수 있다 익명 사용자도 인증이 완료된 것으로 간주하며, ROLE_ANONYMOUS 권한을 갖음 일단 인증이 되어있다. 인가 여부에 따라 응답해줄지, 예외를 던질지 달라진다. AbstractSecurityInterception.att..