HTTP 통신의 특징 중 하나는 바로.. stateless 하다는 것이다. 즉, 서버에 클라이언트의 상태를 저장하지 않는다는 특징이 있다. 그러면.. 로그인은 어떻게 처리할 수 있을까.. 우리 눈에는 웹 페이지를 넘기면서 로그인이 유지되는 것 처럼 보이는데 말이다.. 그래서, 서버에는 클라이언트의 상태를 저장하지 않고 동시에 로그인을 유지하려면... 클라이언트는 서버에게 내가 로그인한 상태라는 것을 지속적으로 알려줘야한다. 이때, 사용되는 기술이 cookie/session 방식과 token 방식이 있다. cookie는 stateless 한 서버를 보완하기 위해 클라이언트에서 내가 누군지 식별하기 위해 서버에 계속 보내는 정보이다. Cookie/Session 방식에 대해 알아보기 전에.. Cookie 방식..

JWT란? RFC 7519 웹 표준으로 지정 되어 있고, Json 을 사용해서 토큰 자체에 정보들을 저장 하고 있는 Web Token이라고 정의 된다. RFC 7519 https://www.rfc-editor.org/rfc/rfc7519 RFC 7519: JSON Web Token (JWT) www.rfc-editor.org JWT 공식 사이트 https://jwt.io/ JWT.IO JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. jwt.io JWT (Json Web Token)의 구성 Header, Payload, Signature 로 .을 ..

소프트웨어 개발에서 변경이 필요할 때... 변경 지점이 하나가 될 수 있도록 설계하고 개발해야한다.. 핵심 기능과 부가 기능을 분리하여.. 부가 기능을 어느 한 군데서만 관리하면 되도록 해보자.. 이를 위한.. 관점 지향 프로그래밍 AOP (Aspect Oriented Programming) AOP는 OOP를 대체하기 위해 나온 프로그래밍 방식이 아니다. 횡단 관심사를 처리하기 어려운 OOP의 부족한 부분을 보조하기 위해 개발되었다. AOP 적용 방법은 총 3가지가 있다. 1. 컴파일 시점에 부가 기능 적용(원본 코드 조작, Weaving) 2. 클래스 로딩 시점에 부가 기능 적용(.class 파일 조작) 3. 런타임 시점에 부가 기능 적용(프록시 방식) 스프링은 위 3가지 방식 중.. 프록시 방식의 A..

지난 포스팅에서는 빈 후 처리기(BeanPostProcessor) 인터페이스를 구현하여.. 프록시를 스프링 빈 저장소에 원본 객체 대신 집어 넣을 수 있었다. (개발자의 개발 대상 : Advisor, BeanPostProcessor) 스프링은.. 역시 개발자를 편하게 해준다.. 스프링은.. 이미.. 프록시를 생성하기 위한 빈 후처리기를 만들어서 제공한다. -> AnnotationAwareAspectJAutoProxyCreator 이다. -> 따라서, 개발자는 Advisor만 개발하면 된다. 이를 위해서.. 아래 라이브러리를 추가 해주자. implementation 'org.springframework.boot:spring-boot-starter-aop' 해당 라이브러리를 추가하면 스프링 부트가 AOP 관..

직전 포스팅에서.. ProxyFactory를 사용하여 프록시 객체를 생성하고 적용하는 방법의 문제점을 다시 적어보겠다.. 1. 수동 빈 등록 시, @Configuration에서 ProxyFactory를 통해 일일이 프록시를 생성하고 리턴 해줘야함.. 2. 컴포넌트 스캔을 통해 자동 빈 등록을 사용하는 클래스는 프록시를 적용할 수 없음 -> 스프링 컨테이너에 타겟 객체가 직접 등록이 되어버려서 개발자가 손쓸수가 없는 상황 이 문제점은.. 스프링에서 제공하는.. 빈 후 처리기(BeanPostProcessor) 로 해결할 수 있다. 빈 후 처리기는.. 스프링이 빈 저장소에 등록할 목적으로 생성한 객체를 빈 저장소에 등록하기 직전에 조작하고 싶을 때 사용한다. -> 다른 객체로 바꿔치기 가능..(프록시로..) ..

앞선 포스팅에서 JDK 동적 프록시 기술과 CGLIB 동적 프록시 기술에 대하여 알아 봤다. 두 기술은 동일하게 프록시라는 기술을 도입하게 해주지만.. JDK 동적 프록시 기술은 인터페이스가 있어야 하고.. CGLIB는 구체 클래스로 프록시를 만들어 낸다.. 그래서 사용법이 달랐다.. 개발자는 편해지고 싶다.. 인터페이스가 있다면 JDK 동적 프록시가 적용되고 구체클래스만 있다면 CGLIB가 적용되게 알아서 해주는건 없나? -> 스프링은 역시 이미 제공하고 있다. 바로 프록시 팩토리 ! 프록시 팩토리에 대해 알아보자.. 선 요약 Advice : 프록시 로직이 들어가고 실제 target 객체 메서드를 호출 Pointcut : 특정 조건이 맞을 때만 프록시가 적용되도록 해줌 프록시에 추가할 로직은 기존에....

이번 포스팅에서는 CGLIB를 통한 동적 프록시 기술에 대해 알아보겠다. JDK 동적 프록시 기술에서는 인터페이스가 있어야 동적으로 프록시를 만들 수 있는 제약 사항이 있었다.. 이를 위한.. CGLIB 동적 프록시 기술!! -> 구체 클래스를 상속해서 프록시를 만든다. CGLIB는 바이트 코드를 조작하여 동적으로 클래스를 생성하는 기술을 제공하는 라이브러리이다. CGLIB는 원래 외부 라이브러리 이지만.. 스프링 프레임워크가 스프링 내부 소스 코드에 포함하여.. 따로 라이브러리 추가 없이 사용 가능 하다. JDK 동적 프록시의 InvocationHandler 인터페이스와 비슷하게.. CGLIB 동적 프록시는 MethodInterceptor 인터페이스를 제공한다. 역시.. reflection 기술을 사용..

이번 포스팅에서는 JDK 동적 프록시에 대해 알아보겠다. 이전 포스팅까지는.. 적용 대상의 숫자 만큼 프록시 클래스를 직접 만들어 줘야 했다.. -> 프록시의 코드는 동일하지만... 적용 대상이 다르기 때문에 적용 대상 갯수 만큼 모두 만들어줘야 했다.. 이를 해결하는.. 동적 프록시 기술! 동적 프록시 기술을 사용하면 개발자가 직접 프록시 클래스를 만들지 않아도 된다.. (런타임에 객체를 동적으로 만들어준다...) 그 중.. JDK 동적 프록시는 인터페이스 기반으로 프록시를 동적으로 만들어준다. -> 따라서 인터페이스가 필수이다. JDK 동적 프록시에 적용할 로직은 위 캡쳐 사진의... InvoationHander 인터페이스를 구현하여 개발하면 된다. 즉, 프록시의 proxy/decorate 로직과 실..