목록이룸 프로젝트 (38)
Kuma's Curious Paradise

클래스명의 이유 **JwtUtil** : jwt 토큰을 다루는 utility 클래스라는 의미 **Util 클래스**란? 특정 기능을 수행하는 static 메서드 & static 필드만을 포함하는 클래스로, 여기저기서 많이 사용되는 메서드나 상수 값을 제공해서 코드 중복을 줄이고 유지 보수가 편리하도록 만듦. 클래스에 붙은 어노테이션 **@Slf4j(topic = "JwtUtil")** : Logger 객체를 자동으로 생성하여 log.info() 와 같은 메서드를 쓸 수 있게 해 주는 lombok 라이브러리의 일부. topic 속성을 통해 로거의 이름을 지정할 수 있음. @Component: 해당 ‘클래스(!!!)’를 bean으로 관리하는 어노테이션. [코드 설명] // Header KEY 값 public..

[문제] cannot resolve column ‘challenge_id’ : intellij 에서 사용하는 database와 연동하여 작성한 컬럼이 존재하는지 체크하는 과정에서 발생하는 것. [해결] View > Tool windows > Persistence 클릭 나타나는 항목을 마우스 우클릭하여 Assign Data Sources 클릭 Data Source 할당인텔리제이 DataSource 할당되어있는지 체크 [적용 결과] 실제 실행에는 문제가 없으니 신경 쓰인다면 요렇게 체크할 것. warning 밑줄이 사라진 것을 확인할 수 있다.
redis란 무엇인가? 개요 레디스(Redis)는 Remote Dictionary Server의 약자로서 '키-값'(key-value) 구조의 비 관계형 데이터를 저장하고 관리하기 위한 NoSQL의 일종이며 모든 데이터를 메모리로 불러와서 처리하는 메모리 기반 데이터베이스 관리 시스템 즉, DBMS다. Redis는 속도가 빠르고 사용이 간편하여 최고의 성능이 필요한 웹, 모바일, 게임, 광고 및 IoT 애플리케이션에서 널리 사용되고 있다. 특징 레디스는 NoSql & Cache 기반의 솔루션이며 메모리 기반으로 구성되어 있다. 메모리 기반인만큼 Redis를 shutdown하거나 서버에 전원 공급이 중지되면 레디스의 데이터는 날아간다. 따라서 레디스는 데이터를 영구 보존하기 위해서 AOF라는 방법을 제공한..
[문제] 토큰 재발급 로직을 구현하였는데, 테스트를 어떻게 진행해야 할지 몰라 먼저 배포를 진행하였다. 이후 프론트와 연결해 보니 구동이 되지 않았다. 나는 토큰 재발급에 대해 무엇을 이해하지 못하고 있는걸까? 토큰 재발급 테스트는 어떻게 진행해야 할까? 문제의 원인 토큰 재발급을 테스트하기 위해 기존의 access token이 만료되기를 하염없이 기다렸다. → 1시간에서 20초로 token time을 수정하였다. 이후 프론트와 테스트를 해 보려 하니, 다른 로직을 테스트하고 있던 팀원들이 access token 만료로 불편함을 겪게 되었다. → 로컬에서 테스트 진행해야 함을 인지하였다. 또한, 프론트와의 테스트에서 아무리 401을 채가서 리디렉션을 해도 500 에러가 터지는 문제가 발생함을 인지하였다...
[문제 상황] 토큰 재발급 로직 구현 중, 토큰이 만료되었음을 어떻게 알 수 있는지 고민하게 되었다. 먼저, 토큰의 만료 여부를 확인하는 방법에는 크게 두 가지가 있었다. 프론트에서 토큰 만료 시간을 저장한 후, 토큰이 만료되기 전에 토큰 재발급 요청을 보낸다. 백엔드에서 토큰의 유효성을 확인한 후, 401 에러를 보내면 프론트에서는 토큰이 만료되었음을 인지하고 토큰 재발급 요청을 보낸다. 이중, 어떤 방법을 선택해야 할까? [해결 방안 고민] 프론트엔드에서 토큰 만료 확인: 서버 부하 감소: 클라이언트 → 요청 → 서버의 401 응답 → 토큰 재발급 요청 → 서버는 토큰 재발급하여 응답 → 다시 요청 → 서버의 200 응답 백엔드에서 토큰 만료를 확인하면 세 번의 요청과 응답을 거치지만, 프론트에서 토..

[문제 상황] 같은 이메일로 카카오 로그인과 일반 로그인을 실행했을 때 500 에러가 터진다. [원인] 카카오 로그인의 refresh-token은 Bearer이 붙어서 저장되고, 아닌 경우 Bearer이 떨어져서 저장된다. 따라서 같은 이메일이 두 개의 refresh-token을 가지게 되어 500에러가 터지는 것으로 가정하고 로직을 수정해 보겠다. [해결 방안] 먼저, 왜 카카오 refresh token에는 bearer prefix가 붙는지 확인하였다. refresh token은 JwtUtil 클래스의 createRefreshToken 메서드에서 만들고 저장한다. 이후 KakaoService 클래스의 kakaoLogin 메서드에서 refresh token을 한번 더! 저장하는 중복되는 로직이 있는 것을..
[문제 발생] ResponseDto로 감싸서 클라이언트에게 데이터를 전달하는 코드 작성 중 ResponseEntity와 ResponseEntity로 다르게 코드를 작성하였다. [원인] 구현 시간이 촉박하여, 다른 이의 코드를 이해하지 못하고 제멋대로 작성한 나..... 에게 문제의 원인이 있었다. 여러 번 읽어 보고 물어보기도 했지만 결국 팀원이 responseDto를 사용한 방식을 이해하지 못했고, baseDto를 extends하는 방식이 더 간결하고 읽기 쉽다고 생각해 일을 저질러 버렸다. [해결방안] 팀원에게 해당 부분을 이야기하고 사죄하였다. 하지만 이렇게 다르게 구현한 김에 두 코드의 장단점을 비교하고 한쪽으로 코드 리팩토링을 진행해 코드 일관성을 갖추고자 하였다. 우리의 다른 점은 baseDt..
HTTP 쿠키의 max-age와 expires 속성은 쿠키의 수명을 정하는 데 쓰인다. max-age는 쿠키가 얼마나 오래 유지될지 초 단위로 정하고, 설정된 시간이 지나면 쿠키는 사라진다. 예를 들어, max-age=3600은 쿠키가 1시간 동안만 유효하다는 뜻이다. expires는 쿠키가 만료되는 날짜와 시간을 지정한다. expires=Sat, 13 Feb 2024 12:00:00 GMT처럼 설정하면 그 시점까지 쿠키가 유지된다. 로그아웃 기능을 구현하면서, 쿠키를 어떻게 할지 프론트와 의논하였다. 프론트에서 쿠키를 삭제하는 방법도 이야기가 됐었는데, 서버에서 새롭게 max-age 값을 0이나 음수로 지정한 토큰을 발부하여 쿠키를 지워버리는 것이 깔끔하고 좋아 보였다. 프론트에서 최대한 토큰에 대해 ..
@Builder 와 @Setter는 무엇이 다를까? @Builder 는 복잡한 객체의 생성 과정을 단계별로 나누어 처리할 수 있는 디자인 패턴인데, 여러 개를 넣어서 하나의 객체를 생성해야 할 때 유용하다. 객체의 불변성을 유지하는 데 도움을 준다는 것이 가장 큰 특징. 체이닝(chaining): 각 설정 메소드가 Builder 객체 자체를 반환하도록 설계되어 있어, 메소드 호출을 연쇄적으로 연결할 수 있다(.method1().method2().build() 형식). 불변성(Immutability): 객체가 한 번 생성된 후에는 변경할 수 없도록 만들 수 있다. 멀티스레드 환경에서 객체의 일관성을 유지하는 데 도움이 된다. 명확한 매개변수 설정: 필요한 속성만 설정할 수 있으며, 객체가 완전히 생성되기 ..
클래스명의 이유 WebSecurityConfig : Spring Security를 사용하여 웹 애플리케이션의 보안을 구성하는 데 사용되는 일반적인 클래스 이름을 사용 클래스에 붙은 어노테이션 @Configuration : 빈을 등록하고 관리함. 여기서는 보안에 관련된 빈은 여기에 모여 있음을 알림. @EnableWebSecurity : Spring Security 설정을 활성화. 저희 시큐리티 사용할게요! 라는 의미. @EnableMethodSecurity(securedEnabled = true) : 메서드 단위로 시큐리티 설정 가능. securedEnable true로 두면 @Secured 어노테이션을 활용한 설정이 가능. 이룸 서비스는 user와 admin으로 역할이 나눠져 있고, 그중 admin만 ..