2025년 02월 17일 TIL

✅ 오늘 할일
- 자기 소개서 작성
- JWT 공부
- 공부한것을 가지고 개인 프로젝트 활용 

JWT

로그인(인증) : 로그인 요청을 받은 후 세션 방식은 서버 세션이 유저 정보를 저장하지만 JWT 방식은 토큰을 생성하여 응답

기본적으로 Security는 Form Login 방식이 디폴트로 되어 있다 하지만 jwt 방식을 사용할려면 FormLogin 방식을 지운다 하지만 FormLogin 방식의 기본적
Filter는 UsernamePassword Authentication Filter(클라이언트가 사용자 이름과 비밀번호를 입력하면 해당요청이 이 필터로 전달됨) 가 사용되지만 지우기 때문에 위 필터를 상속받아 커스터마이징을 해야한다.
그 후 AuthenticationManager 도 커스터마이징을 해 인증을 위해 Repository에서 user 정보를 가져와 UserDetails에 사용자 인증 정보 객체를 담아 가지고와 권한을 검증하여 Successful 관련 메소드를 수행하게 끔 한다 그후
JWT Util을 이용하여 JWT 토큰을 생성하고 클라이언트에 반환 한다.
경로 접근 (인가) JWT Filter를 통해 요청의 헤더에서 jwt를 찾아 검증을 하고 일시적 요청에 대한 세션 생성

활용

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    // todo 경로 별 인가 작업

    @Bean
    public BCryptPasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity httpSecurity) throws Exception {

        httpSecurity
                .csrf(AbstractHttpConfigurer::disable);

        httpSecurity
                .cors(AbstractHttpConfigurer::disable);

        httpSecurity
                .formLogin(AbstractHttpConfigurer::disable);

        httpSecurity
                .httpBasic(AbstractHttpConfigurer::disable);

        httpSecurity
                .sessionManagement((session) -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS));

        httpSecurity
                .authorizeHttpRequests((auth) -> auth
                        .requestMatchers("/api/users/**", "/signup", "/login").permitAll()
                        .anyRequest().authenticated());

        return httpSecurity.build();
    }
}

@EnableWebSecurity 어노테이션으로 스프링 시큐리티를 활성화 한다.
그 후 BCryptPasswordEncoder를 빈으로 등록하여 사용자 비밀번호에 대한 db에 저장할 때 암호화 처리를 할수 있도록 한다.
HttpSecurity 를 통해 CSRF,CORS,로그인 방식, 세션 정책 ,인가 설정을 수행한다.
CSRF 란?
사용자가 공격자가 의도한 행위(수정,삭제,등록 등)를 특정 웹사이트에 요청하게 하는 공격
CORS 란?
도메인이 다른 서버끼리 리소스를 주고 받을 때 보안을 위해 설정된 정책

궁금증

public class UserDto {

    @Getter
    public static class SignUpRequestDto {

        @NotNull
        private String name;
        @Email
        private String email;
        @NotNull
        private String password;
    }

}

이럴게 dto 로 만드는게 나을까 아니면 평소에 만들던 것 처럼 SignUpRequestDto, 따로 LoginRequestDto 따로 만드는게 나을까
궁금증이 생겼다. 팀 컨벤션에 따라 달라지겠지만 개인 프로젝트에서 생각해 보면 위 코드 처럼 만드는 장점은 DTO를 한곳에서 관리가 가능하고 코드 가독성 및 유지보수 가 향상되는 장점이있다고 보았다.
하지만 DTO 수가 많아 질 경우 관리가 편하다는 장점이 단점으로 바뀔 것 같다. 사용해 보면서 장점이 더 부각 되는 것으로 사용해야겠다.