Mason

CORS(Cross Origin Resource Sharing) CORS란 서로 다른 출처의 요청이더라도 서버의 리소스를 사용할 수 있도록 해주는 설정이다. 항상 SecurityFilterChain에 csrf().disable() 만을 사용하다가 팀 프로젝트를 앞두고 좀더 보안이 강화된 CORS 설정이 필요할 것 같아 알아보게 되었다. 찾아낸 방법으로는 3가지가 있었다. Spring MVC의 Controller에 직접 CORS 설정 Spring MVC에서 WebMvcConfigurer를 구현하는 설정 bean 등록 Spring Security에서 설정 bean 등록 방법 1. Spring MVC의 Controller에 직접 CORS 설정 제일 직관적인 방법이다. @RestController @CrossO..

멤버 엔티티 @Entity @NoArgsConstructor @Getter @Setter public class Member extends Auditable { ... ... @Enumerated(value = EnumType.STRING) @Column(length = 20, nullable = false) private MemberStatus memberStatus = MemberStatus.MEMBER_ACTIVE; ... ... public enum MemberStatus{ MEMBER_ACTIVE("활동중"), MEMBER_SLEEP("활동 중지"), MEMBER_QUIT("활동 정지"); @Getter private String status; MemberStatus(String status) ..

처음 시작은 게시판의 게시글을 post 하기 위한 DTO를 작성하고 요청을 보내 테스트하던중 UnexpectedTypeException 예외가 발생하였다. (해당 예외 이름에서 알 수 있듯이 요청으로 받은 JSON 파일이 다른 타입을 제공하고 있어서 발생한 예외이다. 이것만 좀더 일찍알았더라면 2시간을 허비하지 않았을텐데...) 발생한 예외의 DTO와 Enum 코드 DTO public class PostsDto { @Getter @Builder @Setter public static class Post{ ... ... @NotBlank private String title; @NotBlank // 예외 발생지점 private Posts.PostStatus postStatus; @NotBlank priva..

회원에 관한 CRUD 서비스를 완성하고 회원을 등록했을때 발견된 버그이다. 위의 그림을 살펴보면 CREATED_AT, LAST_MODIFIED_AT, MEMBER_STATUS 컬럼이 비어있다. JPA에서는 참조 타입에 입력값이 없는경우 null로, int와 같이 정수형 원시타입의 경우 0으로 채워져 저장된다. 버그1 - MEMBER_STATUS에 열거형 데이터 적용 public class Member extends Auditable { ... ... @Enumerated @Column(length = 20, nullable = false) private MemberStatus memberStatus = MemberStatus.MEMBER_ACTIVE; ... ... public enum MemberSta..

Spring Security의 인증부분을 공부하던 도중 SecurityContextHolder에 관해 의문점이 생겨 포스트를 작성하게 되었다. SecurityContextHolder는 위와 같이 Spring Security에서 UsernamePasswordAuthenticationFilter에서 인증작업을 모두 마친 후 UserPasswordAuthenticationToken을 SecurityContextHolder에 담아 보관하게 된다. 하지만 공부 도중 실습단계에서 구현한 코드에는 해당 내용을 찾을 수 없엇다. 대신 OncePerRequestFilter를 상속받는 또 다른 Filter에서 SecurityContextHolder를 찾을 수 있었다. public class JwtVerificationFi..

JWT를 알아보기 전에 Token기반과 Session기반 인증의 차이에 대해 알아보자. 세션 기반 자격 증명 방식 세션 기반 자격 증명 방식은 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소(DB)에 저장하는 방식이다. 즉, 클라이언트 측에서 서버 측으로 요청이 들어오면 서버 측에서는 사용자를 식별하기 위해 세션 저장소에 저장된 세션 정보와 사용자가 제공하는 세션이 일치하는지 확인하는 인증 작업을 거친 뒤 인가 처리를 진행한다. 세션 기반 자격 증명의 특징 세션은 인증된 사용자 정보를 서버 측 세션 저장소(DB)에서 관리한다. 생성된 사용자 세션의 고유 ID인 세션 ID는 클라이언트의 쿠키에 저장되어 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다. 세션 ID만 클라이언..

DelegatingPasswordEncoder DelegatingPasswordEncoder는 Spring Security에서 지원하는 PasswordEncoder 구현 객체를 생성해 주는 컴포넌트로써 DelegatingPasswordEncoder를 통해 애플리케이션에서 사용할 PasswordEncoder를 결정하고, 결정된 PasswordEncoder로 사용자가 입력한 패스워드를 단방향으로 암호화해준다. // PasswordEncoder 객체 생성 PasswordEncoder passwordEncoder = PasswordEncoderFactories.createDelegatingPasswordEncoder(); // PasswordEncoder 사용 passwordEncoder.matches((Str..

SecurityFilterChain HttpSecurity 인스턴스를 매개변수로 받아 SecurityFilterChain으로 만들어준다. 이전 포스트, Spring Security Filter의 동작 흐름에 기재된 것과 같이 SecurityFilterChain은 DelegatingFilterProxy와 FilterChainProxy를 통해 Servlet filter와 연결된다. @Configuration public class SecurityConfiguration { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception{ http .headers().frameOptions().sameOrigin() // (1) ..

이전 포스트에서 클라이언트의 요청이 Spring Security Filter까지 도달하는 과정을 포스트 했었다. 이번 포스트에서는 도달한 사용자의 인증 요청이 Spring Security Filter Chain의 특정 Filter에 도달했을 때, Spring Security의 컴포넌트들이 어떤 과정을 거쳐 사용자의 인증 요청을 처리하는지 그 흐름에 대해 포스트 할 예정이다. Spring Security의 인증(Authentication) 처리 흐름 위의 그림은 개발자가 지정한 특정한 URL(로그인)으로 포스트요청이 들어왔을때의 처리 흐름이다. 먼저 (1)에서 사용자가 로그인 폼 등을 이용해 Username(로그인 ID)과 Password를 포함한 request를 Spring Security가 적용된 애플..

Filter 구현 public class FirstFilter implements Filter { // (1) 초기화 작업 public void init(FilterConfig filterConfig) throws ServletException { Filter.super.init(filterConfig); System.out.println("First Filter 생성"); } // (2) public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { // (2-1) request(ServletRequest)를 이용해 다음 Filter로 ..