Spring Security + JWT의 한계를 DB로 보완해야하는 이유
·
Spring
들어가면서이 글은 Spring Security의 기본 JWT 방식이 아닌, `JWT와 인증 테이블(DB)을 함께 사용한 인증`을 구현할 때의 고민을 다루며, `블랙리스트 토큰 테이블을 활용한 로그아웃 방식`에 대해 설명한다.JWT 기반 인증에 대한 배경지식이 있다면 더욱 이해가 쉬울 것이다. 기본 JWT 방식의 특성과 한계JWT 방식은 무상태(stateless) 기반이다. 즉, `서버에 토큰 정보(사용자 정보, 만료 시간 등)를 저장하지 않는다.`이로 인해 다음과 같은 문제가 발생한다:`토큰 관리가 불가능하다`: 로그아웃 시 서버는 토큰을 폐기하거나 무효화할 수 없다.`Refresh Token도 서버에 저장하지 않는다`: Access Token 만료 시 자동 재발급이 어렵다.`Access Token ..
Spring 프로젝트에 로컬 캐시를 도입해보자.
·
Spring
들어가며스프링을 기반으로 한 팀 프로젝트를 개발하면서, 성능 최적화를 해보고 싶었습니다. 그 와중에 떠오른 게 바로 캐시입니다. 개념만 살짝 알고 있었는데 이번 포스팅을 통해서 글로벌 캐시가 아닌 로컬 캐시를 선택한 이유 그리고 가장 중요한 캐시의 검증 을 로그를 통해 알아보겠습니다.   로컬 캐시를 선택한 이유 캐시 전략에는 크게 두 가지 유형이 있습니다글로벌 캐시:여러 대의 서버를 사용하는 환경에서 별도의 캐시 서버를 구축하여 사용합니다.장점: 분산 서버 환경에서 효율적입니다.단점: 외부 캐시 서버와의 네트워크 비용이 발생하며, 별도의 캐시 서버 구성이 필요합니다.로컬 캐시:각 서버 인스턴스의 자원을 사용하여 캐시를 구성합니다.장점: 구현이 간단하고, 하나의 서버 인스턴스에서 운영될 때 글로벌 캐시에..
[Spring] 의존성을 주입해주는 주체 - jar, @Profile, @Order
·
Spring
의존? 의존성?의존, 의존성 -> Dependency의존(성) 주입 -> Dependency Injection의존(관계) 역전 -> Dependency Inversion   스프링 프레임워크가 해주는 일-> 스프링 빈에서 @Component 들을 갖고 있으며, 컴포넌트의 생성자에서 의존성 주입을 해준다.    실행 시점에 어떻게 다른 빈을 주입시켜줄까?@SpringBootApplicationpublic class ChangeRepositoryMain { public static void main(String[] args) { SpringApplication.run(ChangeRepositoryMain.class, args); }}@RestControllerpublic class C..
[Spring] 의존 주입 패턴을 예제와 함께 알아보자.
·
Spring
의존 주입 패턴이란?  public interface Repository { void someMethod(String articleContent);}public class DatabaseRepository implements Repository { @Override public void someMethod(String articleContent) {}}public class FileRepository implements Repository { @Override public void someMethod(String articleContent) {}}@Componentpublic class Service { private Repository repository; publ..
[Spring] 의존 역전에 대해 알아보자.
·
Spring
의존 역전이란 무엇인가?고수준 컴포넌트가 저수준 컴포넌트에 의존하지 않도록 의존 관계를 역전시키는 것컴포넌트는 클래스를 의미인터페이스로 의존 방향이 모이도록 하는 것   고수준 컴포넌트와 저수준 컴포넌트의존 방향 ->게시글 작성Controller -> Service -> RepositoryService -> Repository 에서는 클라이언트가 요청한 게시글이 DB 에 저장되도록 요쳥게시글 조회Controller -> Service -> RepositoryService -> Repository 에서는 클라이언트가 요청한 게시글을 DB 에서 조회  현재 구조에서는 어떤 문제점이 있을까?-> Service 에서 상황에 따라 필요한 Repository 를 바꿔야할 때, Service 의 코드를 바꿔줘야한다...