Everyday Dev System

먼저, 로그인을 하면 JWT 토큰을 재발급 해줍니다. 예를 들어 JWT 토큰의 만료 시간이 1시간일 경우, 1시간마다 로그인을 해주어야 합니다. 이러한 번거로움과 엑세스 토큰의 탈취를 염려하여 리프레시 토큰을 추가했습니다. Refresh Token 도입 쿠키에 토큰을 저장하는 방식을 선택하였고, 쿠키에 만료 시간을 설정하여 웹 브라우저에서 쿠키가 만료가 되면 자동으로 삭제하도록 하였습니다. 이는 웹 브라우저에서 제공하는 기능입니다. 도입 배경 : 만료 이전의 엑세스 토큰이 탈취되면 이를 활용할 할 수 있다는 문제 발현 보안적인 측면과 사용자의 편의성을 고려하여 Refresh Token을 도입. 목적 : 인증 과정에서 보안적인 측면을 강화 보안적인 측면을 고려함으로써 감소하는 사용자의 편의성 또한 보완 인..

참조: https://www.notion.so/azuressu/f88358f2cfa74951ad4482235b955b06 트러블 슈팅 🔔 알림 🔔 www.notion.so Redis 저장소 활용의 용이성 Redis의 장,단점 빠른 I/O 처리가 가능하다. 인메모리 형태의 저장소이다. key- value 형태로 저장이 되고, 다양한 형태의 저장도 가능하다. 테이블 구조가 정형화 되어 있는 RDBMS의 단점을 보완할 수 있다. 스키마가 정해져 있지 않아 확장성이 좋다. 단점으로는, 테이블 구조가 정형화 되어 있지 않아 JOIN문을 실행할 수 없다. 이메일 인증번호 데이터 수명 주기 회원가입 시 이메일을 입력하고 해당 이메일을 인증하는 절차를 거친다. 이때 이메일에 따른 랜덤값을 인증번호로 갖는데, 이를 어떤..

캐시는 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다. 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있다. 즉, 캐시는 접근 비용이 비싼 데이터의 사본을 만들어 저장하고, 동일한 요청이 있을 때 원본 데이터에 접근하지 않고 사본 데이터를 제공할 수 있게 하는 중간 장치의 개념입니다. 병목 현상이 일어날 수 있는 지점의 성능 향상을 위해 캐시를 사용합니다. 그럼 어떠한 Cache 기술을 적용할지 고려해보자. Cache 관리 전략을 선택할 때 가장 먼저 고려해야 할 요소는, 캐시 데이터를 저장할 스토리지를 서버가 자체적으로 ..

서버에서 발급한 Access Token 및 Refresh Token을 어디에 저장해야 할까? 현재 상황 현재 제 프로젝트에서 JWT 토큰을 활용합니다. Access Token이 탈취됐을 때 대비를 위해 Refresh Token 개념을 도입하여, 두 토큰 모두 쿠키에 저장했습니다. 쿠키에 담아 JS 파일에서 토큰 여부를 확인하기 위해 setHttpOnly()를 설정하지 않았습니다. 문제점 클라이언트 측에서 둘다 갖고 있으면 탈취 당할 가능성이 있지 않을까? 고민 먼저, JWT 인증은 서버가 상태를 갖지 않아 클라이언트 측에서 토큰을 저장하고 있어야 합니다. 클라이언트가 사용할 수 있는 저장소는 쿠키, 세션 스토리지, 로컬 스토리지가 있습니다. 이 중 어떤 저장소에 저장할지 선택하기 위해 각 저장소별 차이점..

Access Token과 Refresh Token을 처리할 때 문제점을 발견했습니다. 로직을 요약하면, 클라이언트의 로그인 요청 서버에서 Access Token과 Refresh Token 생성 및 반환 (Refresh Token Redis에 저장) 클라이언트에서 Access Token과 Refresh Token을 쿠키에 저장 (HttpOnly설정) 이와 같습니다. 먼저, Access Token이 만료되기 이전에 요청은 Spring Security Filter Chain을 잘 거쳐 Controller 단에 도달하여 해당 요청(재발급)을 잘 처리합니다. 문제는 만료된 Access Token 으로 요청시 Controller 단에 도달조차 못 한다는 것입니다. 이는 Filter에서 토큰 검증을 거치기 때문에 검..

Success : AJAX 요청이 성공적으로 완료되면 이 콜백이 트리거됩니다. 응답 상태 코드가 성공을 나타낼 때(일반적으로 2xx 범위) 서버에서 반환된 데이터를 처리하는 데 사용됩니다. 이 콜백에서는 수신된 데이터를 처리하고 조작할 수 있습니다. 오류 : 클라이언트 측이나 서버 측에서 AJAX 요청에 오류가 발생하면 오류 콜백이 호출됩니다. 여기에는 응답 상태 코드가 오류(예: 4xx 또는 5xx 상태 코드)를 나타내는 경우가 포함됩니다. 이 콜백을 사용하면 오류를 처리하고 관리하여 사용자에게 적절한 피드백을 제공할 수 있습니다. Done : AJAX 요청이 성공했는지 또는 오류가 발생했는지 여부에 관계없이 "done" 콜백이 실행됩니다. 결과에 관계없이 AJAX 요청이 완료된 후 수행하려는 작업에 ..

문제점 : js 파일에서 cookie 값을 조회하려고 하였으나, 조회가 되지 않는 문제가 발생했습니다. let token = Cookies.get('Authorization'); console.log(token); 시도 : 1. Cookies.get().value를 하여 저장이 되나 시도해 보았습니다, 그럼에도 계속 undefined 로 출력이 되어 해결되지 않았고, 오히려 value로 값을 저장할 수 없다는 에러가 발생했습니다 let token = Cookies.get('Authorization').value; console.log(token); 2. 쿠키에 값이 setting이 되지 않은 것은 아닌지 get()을 통해 모두 참조해보았습니다. 이 방법 역시 계속 undefined 로 출력이 잘 됐습니다..

해당 글에서는 docker 컨테이너에 redis 설치하여 활용하는 방법에 대해서 시도해보겠습니다. 환경 설정 (설치) 먼저 git bash에서 docker로 부터 Redis 공식 이미지를 불러와서 6379번 포트로 Redis를 실행하는 .yml 파일입니다. 해당 파일을 build 시켜줍니다. build 전에 docker desktop을 실행시켜주셔야 합니다. 위와 같이 docker desktop에 해당 이미지가 생성되어 해당 이미지로부터 Redis 컨테이너가 실행되고 있습니다. redis-cli 명령어 실행 cmd를 관리자 권한으로 실행하여 docker exec -it redis bash를 입력하여 Redis 컨테이너를 cli 환경에서 접근할 수 있습니다. Redis는 다양한 자료구조를 지원합니다. St..

Swagger를 활용하기 위해 springfox 라이브러리를 활용하기 위해 시도해보았습니다. // swagger implementation 'io.springfox:springfox-boot-starter:3.0.0' 문제점: Type javax.servlet.http.HttpServletRequest not present 이는 스프링 부트3을 지원하지 않는 라이브러리인 springfox swagger를 시도하다 마주한 문제입니다. 스프링 부트3.1.2 버전인 해당 프로젝트에서 springfox swagger를 사용하기 위해 시도해보았으나, 위와 같은 에러를 마주했습니다. 이는 springfox swagger가 javax 패키지를 jakarta로 변경하지 않아 생기는 문제입니다. Spring Boot 3..

SpringFox 및 Spring Boot 버전의 컨텍스트에서 @EnableSwagger2 및 @EnableSwagger2WebMvc 주석에 차이가 있습니다. @EnableSwagger2: SpringFox 버전 2.x 및 이전 버전에서 사용됩니다. Spring Boot와 Swagger 2 통합을 가능하게 합니다. 최신 버전의 Spring Boot, 특히 Spring Boot 2.5 이상에는 최선의 선택이 아닐 수 있습니다. @EnableSwagger2WebMvc: Spring Boot 2.5+와의 더 나은 호환성을 제공하기 위해 SpringFox 버전 3.x에서 도입되었습니다. Spring Boot의 WebMvc 구성과 잘 작동하도록 특별히 설계되었습니다. 최신 Spring Boot 버전(2.5 이상)..