https://www.youtube.com/watch?v=K00xh3zsof0 해당 유튜브를 보고 정리한 내용입니다. 우선 내가 아는 HTTP는 무상태다. 즉 클라이언트가 서버에 연결을 요청하면 TCP/IP 통신을 통해 가상 연결을 진행하고, 서버는 HTTP 요청을 받아서 RESPONSE를 내뱉으면 연결은 끊어진다. 그러면 현재 유저가 로그인 된 상태인지는 어떻게 알까? 로그인의 경우 크게 JWT, 세션을 사용한다. 즉 클라이언트에게 토큰이든 세션ID든 쿠키에 담아서 전달해주게 되는데, 해당 쿠키를 같이 서버로 전달해주면서 유저의 로그인 상태를 확인한다. 그럼 서버는 유저의 정보를 어디에 저장하냐? 그게 데이터베이스(DB)다. 결국 클라이언트는 쿠키로 기억, 서버는 DB로 기억하고 서로의 연결을 확인하게..
분류 전체보기
나는 여태 프로젝트를 진행하면서 Class에 lombok을 사용해서 @Builder 어노테이션으로 Entity를 생성했다. 클래스에 @Builder를 붙이면 해당 클래스가 가진 모든 필드를 파라미터로 넣어서 객체를 생성해야 했기에 Entity를 생성하는 데 적합하다고 생각해서였다. 그런데 오늘 나왔던 얘기중에 Class에 @Builder를 붙이지 말고, 생성자를 만들어서 해당 생성자에 @Builder를 붙이라는 말씀이 나왔다. 우선 @Builder에 대해 자세하게 알아봐야한다. 디자인 패턴중에서 빌더 패턴을 사용하면 인스턴스를 생성할 때 명시적으로 파라미터를 넣어줄 수 있다는 장점이 있다. 또한 파라미터 순서대로 넣지 않아도 된다는 아주아주 큰 장점이 있다. 만약에 빌더를 사용하지 않고 생성자로 인스턴스..
JPA는 DB에 반영이 돼야 하는 변화가 생기면 영속성 컨텍스트에 모아두고 트랜잭션이 커밋되는 시점에 한 번에 데이터베이스에 반영시킨다. 이것을 쓰기 지연 전략이라고 한다. 분명 나는 개념을 이렇게 알고 있었고, 문제는 아래의 테스트에서 발견됐다. @BeforeEach void setUp(){ User user = User.builder() .email("test@test.com") .profileImage("ex") .nickname("ex") .isOnline(false) .type("kakao").build(); User save = userRepository.save(user); System.out.println(save.getId()); } User 객체를 하나 생성하고 save를 진행한다. 그..
현재 AccessToken, RefreshToken을 전부 쿠키로 담아서 전송하도록 만들었다. 심심해서 쿠키에 있는 AccessToken을 조금 바꿔서 swagger로 전송을 보냈더니 바로 SignatureException을 뱉어내기 시작했다. 문제는 내 코드에 해당 에러를 처리해주는 부분이 없었다는 거. 그래서 응답으로 이렇게 500에러가 터져버린다. 그래서 토큰에서 값을 파싱할 때 해당 예외처리를 진행해주었다. public Long getUserId(String token){ try { return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token) .getBody().get("userId", Long.class); } catch (Expir..
현재 서버에 배포한 Swagger로 테스트를 진행하는데 계속 403 에러가 발생했다. 이것도 마찬가지... 근데 이상한 점이 있었다 GET 요청은 응답이 제대로 온다. 서버 로그를 찍어봤는데 GET 요청 말고는 JWT필터도 타지 않는다. 즉 시큐리티도 안들어오는데 이상하다 분명 먼저 내용을 찾아보니 csrf를 허용해놓으면 post, patch, delete, put이 403이 뜰 수 있다고 했다. // csrf 보호 비활성화 .csrf(AbstractHttpConfigurer::disable) 근데 시큐리티 설정에 disable을 이미 해놨기에 이 부분은 패스했다. 알고보니 결국 cors 문제였다. 내가 알기로는 cors 문제가 생기면 swagger에서 cors 문제라고 알려줬었는데 왜 안떴는지 아직은 ..
스프링부트 : 3.20 현재 백엔드는 정상 배포를 해놨지만 스웨거는 로컬에서만 사용했다. 이렇게 서버가 http://localhost:8080으로 두고 뒤에 api 경로를 넣어서 테스트를 진행했었는데 스웨거를 반만 사용하는 느낌이 들었다. API 명세를 간편하게 관리한다는 장점이 있지만, 동시에 프론트가 따로 postman이나 로컬 서버를 켜지 않더라도 스웨거 테스트를 통해 입력과 출력을 봐야 한다는 생각이 들었다. 그래서 배포해놓은 주소로 스웨거를 들어가봤다. 들어가지긴 하는데 기본 서버가 http://localhost:8081로 잡혀있다. 근데 여기서 의문이 생겼던 점은 왜 8081로 잡히는가? 였다. 현재 로컬에 있는 yml과 도커에 있는 yml은 다른 게 없다. 심지어 스프링부트 포트 설정도 그대..
스프링 부트 : 3.2.0 여태 SSAFY에서 진행했던 프로젝트에는 프론트에서만 유효성 검사를 진행했다. (?) 그 당시에는 '값만 제대로 넘겨주면 상관없지 않나? 귀찮다' 이 생각이었는데 만약에 값이 수정되거나 잘못된 경로로 들어오게 된다면? 서버에서 문제가 발생하게 된다. 이걸 막아주기 위해서 서버에서도 유효성 검사를 필히 진행해야한다. 우선 유효성 검사를 진행할 부분은 총 3가지로 판단했다. Entity Entity는 기존에 제약조건을 걸어두었던 상태다. 그러나 제약 조건은 테이블을 만들 때 해당 조건에 따라 테이블이 생성되는 것일 뿐. 만약에 조건에 부합하지 않는 값이 들어오면 DB에서 에러를 뱉어내게 된다. Entity에도 유효성 검사를 진행했던 이유는 빌더를 통해 객체를 생성하는 데 이때 유효..
Service의 테스트코드를 작성하다가 아래의 문제를 마주쳤다.즉 User라는 클래스에 id가 null인 경우다. @BeforeEach void set_up(){ // given accessToken = "test_access_token"; userId = 1L; mockUser = User.builder() .email("test@test.com") .profileImage("test") .n..
