토큰 기반 로그인 방식 에서는 사용자가 로그인을 하면 서버가 사용자를 식별할 수 있는 최소한의 정보와 만료 시간 등을 포함한 토큰을 발급해준다. 사용자는 이후 요청을 보낼 때 이 토큰을 서버에 함께 보내고, 서버는 해당 토큰을 검증해 인증과 인가를 처리한다. 해당 방식은 어떤 서버에서 토큰을 발급했든 클라이언트가 보내온 토큰만 확인하면 인증과 인가가 가능하기 때문에, 여러 서버를 운영하는 환경에서 특히 편리하게 사용할 수 있다. 서버 측에서는 해당 토큰이 내가 발급해 준게 맞는지 확인할 수 있는 비밀키를 제외하고 아무것도 서버측에 저장하지 않는다. 이런점 덕분에 서버 인스턴스를 수평 확장할 때 세션 방식보다 유리하고, 별도의 세션 저장소를 두지 않아도 되기 때문에 서버 저장 공간도 아낄 수 있다. ..

서블릿 필터는 기본적으로 서블릿 컨테이너가 관리하기 때문에 스프링 DI 컨테이너에서 직접 관리할 수 없다. Spring Boot를 사용하면 서블릿 컨텍스트와 스프링 컨텍스트를 연결할 수 있으며, FilterRegistrationBean이나 @Component를 이용해 필터를 스프링 빈으로 등록할 수 있다. Spring Boot를 사용하지 않을 경우 DelegatingFilterProxy를 이용하여 이를 해결할 수 있는데, Spring Security는 이를 통해 서블릿 필터 체인과 스프링 빈을 연결한다. DelegatingFilterProxy는 서블릿 필터 체인과 스프링 컨테이너 사이에서 두 환경을 연결해주는 다리 역할을 한다. 클라이언트의 요청이 발생하면, 해당 요청은 먼저 ..

북마크 생성하기 같은 인증 / 인가 작업이 선행되어야하는 요청이 왔을 때, 사용자가 누구인지 식별하고 북마크 생성을 위한 권한이 있는지 검사하기 위해, 사용자에게 로그인을 먼저 하도록 요구해야 한다. 하지만 무상태 프로토콜인 HTTP를 사용할 경우 별도의 추가 조치가 없다면 사용자가 북마크 생성을 요청할 때 마다, 로그인 절차를 반복해야 한다. 사용자의 로그인 상태를 유지하기 위해서 별도의 조치가 필요하다. 가장 쉽게 시도할 수 있는 방법은 쿠키를 사용하는 것이다. 쿠키는 서버가 사용자의 웹 브라우저 전송해 두었다가, 사용자의 재 요청시 서버로 함께 전송되는 데이터 조각이다. 이를 사용자의 상태를 유지하는 데 사용할 수 있다. 하지만 이렇게 쿠키만으로 인증 상태를 유지하면 여러 문제가 발..

https://backend-newbie.tistory.com/47 , 이전 포스팅에서 Redis를 우리 서버의 글로벌 캐시로 선정하는 과정을 다루었다. 이번에는 이를 실제로 적용해 볼 생각이다. Lettuce, Jedis 커넥터를 사용하고 싶다면 Spring Data Redis에서 내장해서 지원하지만, Redisson의 경우 별도로 추가해줘야 했다. implementation 'org.springframework.boot:spring-boot-starter-data-redis'implementation 'org.redisson:redisson-spring-boot-starter:3.43.0' 나는 redisson을 이용한 분산락을 사용하고 있기 때문에 위와 같이 두 가지 의존성을 추가해 ..

https://backend-newbie.tistory.com/46 , 이전 포스팅에서 분산락 도입을 끝냈다. 이번에는 실제로 API 응답을 위해 필요한 데이터들을 캐시하기 위해서 캐시 설계를 진행할 생각이다. 내가 캐시에 저장해야 할 데이터는 GitHub의 follower와 following 조회 API 응답 중 필요한 필드만 골라낸 값이다. 팔로워 리스트와 팔로잉 리스트, 그리고 스냅샷 시각으로 이루어져있다. 여기서 보통 실제 팔로우 리스트에 들어있는 깃허브 유저 데이터 하나는 40~80 byte 정도의 용량을 갖고 있다. 크게 id, usertag, 프로필 url이 필요한데 id의 경우 Integer로 정해져 있고 4 byte 고정이다. GitHub 응답의 login에 해당하는 us..

https://backend-newbie.tistory.com/45 , 이전 포스팅에서 문제 상황을 MySQL 네임드 락으로 해결하려다가 Redis 기반 분산락을 사용하는게 더 좋은 선택지가 될 것 같아서 변경하게 되었다. SET lockKey lockValue NX PX expire Redis로 분산락을 구현하기 위해서는 위와 같은 명령어를 사용하면 된다. Redis의 SET 명령어에는 NX/XX 라는 옵션이 존재한다. NX의 경우 값이 존재하지 않으면 세팅해 달라는 의미이다. XX의 경우 키가 존재하는 경우에만 저장하라는 의미이다. EX/PX 라는 옵션도 존재하는데 EX의 경우 초단위로 TTL을 지정할수 있고, PX의 경우 밀리 초 단위로 TTL을 지정할 수 있다. 즉, 위의 명령어는 lo..

https://backend-newbie.tistory.com/44 , 이전 글에서 API를 설계해 보면서 분산락이 필요해 보이는 상황이 생겼다. 사용자가 해당 API를 호출 했을 때, 응답에 필요한 데이터가 준비된 상황이라면 200 OK와 응답 데이터를, 준비되지 않은 상황이라면 202 Accepted를 응답으로 보내주고 서버 내부에서 데이터를 준비하는 작업을 실행하는 상황이다. 어떤 사용자가 최초로 맞팔탐지기 조회 요청을 하게 되면, 실제 응답을 위해 데이터를 받아오는 데 5초 정도의 시간이 걸린다고 가정했다. 이 때, 사용자측에서 기다리지 않고 계속 동일한 API를 호출하면, API 서버 쪽에서는 아직 응답을 위한 데이터가 캐시에 존재하지 않는다고 판단하여 계속 깃허브에서 데이터를..

이번 프로젝트에서 위와 같이 우리 서비스에서 사용자의 깃허브 팔로우 관계를 탐지하고 관리할 수 있는 기능을 담당하게 되었다. 위의 API를 구현하기 위해서 위와 같이 사용자의 followers, following을 모두 조회하는 API를 이용했다. 깃허브에는 나만 팔로우중인 유저 리스트 조회, 맞팔로우 중인 유저 리스트 조회, 상대만 나를 팔로우 중인 리스트 조회를 위한 API는 따로 제공하지 않는다. 해당 API들은 사용자의 Follower와 Following이 너무 많다면 한 요청에 100명의 응답을 준다는 제약 조건을 가지고 있다. UI를 분석해 보면, 우선 사용자의 전체 팔로잉, 팔로워 리스트가 있어야 보여줄 수 있는 "00명과 맞팔로우 중입니다." 와 같은 통계 정보와..