Everyday Dev System

1. 프로젝트 개요 프로젝트 명 : "Elephant " 프로젝트 한줄 소개 : 개발자 및 개발 공부를 하는 사람끼리 서로 정보를 공유하고 협업 프로젝트 팀을 구성해 사이내에서 다양한 협업 지원 기능을 이용할 수 있습니다. 도메인 주소 : https://www.elephantcodingclub.site/ (현재 서버 OFF) 시연 영상 : https://www.youtube.com/watch?v=5RR0kAxlCGY 팀노션 : https://www.notion.so/azuressu/a1c7ce1ccb874da0b1f4b99050bd295d Repository : https://github.com/sangbu3jo/Elephant GitHub - sangbu3jo/Elephant Contribute to ..

먼저, 로그인을 하면 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 관리 전략을 선택할 때 가장 먼저 고려해야 할 요소는, 캐시 데이터를 저장할 스토리지를 서버가 자체적으로 ..

0. 상부삼조하는 우리 팀의 소통의 광장 Notion https://azuressu.notion.site/3-a1c7ce1ccb874da0b1f4b99050bd295d 3조 - 최종 프로젝트 우리 팀 상부삼조 azuressu.notion.site 1. 시연 영상 https://youtu.be/jAUw7nbltM0 2. Github Repository https://github.com/sangbu3jo/Elephant GitHub - sangbu3jo/Elephant Contribute to sangbu3jo/Elephant development by creating an account on GitHub. github.com 3. 기능사항들 로그인 / 회원가입 / 로그아웃 JWT 토큰 발급 및 Redis ..

서버에서 발급한 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 로 출력이 잘 됐습니다..