nothing_is_in_my_way

이전 포스팅에서 회원 가입 시 등록한 이메일 주소, 패스워드를 통해 로그인 인증을 성공적으로 수행하면 response header(Authorization, Refresh)를 통해 JWT를 전달받을 수 있었다. 이번 포스팅에서는 클라이언트 측에서 JWT를 이용해 자격 증명이 필요한 리소스에 대한 request 전송 시, request header를 통해 전달받은 JWT를 서버 측에서 검증하는 기능을 구현해 보자. 1️⃣ JWT 검증 필터 구현 JWT를 검증하는 전용 Security Filter를 구현하는 것. package com.codestates.todoapp.auth.filter; import com.codestates.todoapp.auth.jwt.JwtTokenizer; import com.co..

JWT 자격 증명을 위해 로그인 인증 기능부터 구현해 보자. Username과 Password로 로그인 인증에 성공하면 로그인 인증에 성공한 사용자에게 JWT를 생성 및 발급하는 것까지를 먼저 구현해본다. JWT 자격 증명을 위한 로그인 인증 기능을 구현하기 위해 먼저 로그인 인증 흐름을 간단하게 확인해보자. 사용자의 로그인 인증 성공 후, JWT가 클라이언트에게 전달되는 과정은 다음과 같다. 1. 클라이언트가 서버 측에 로그인 인증 요청(Username / Password를 서버 측에 전송) 2. 로그인 인증을 담당하는 Security Filter(JwtAuthenticationFilter)가 클라이언트의 로그인 인증 정보 수신 3. Security Filter가 수신한 로그인 인증 정보를 Authen..

웹 애플리케이션을 공격하는 세션 고정 공격, 클릭재킹 공격, CSRF 등의 보안 취약점을 고려하기 위해서는 Spring Security라는 보안 프레임워크를 이용할 수 있다. *세션 고정 공격(Session Fixation) : 공격자가 유효한 사용자의 세션을 가로채도록 허용하는 공격. 이 공격은 웹 애플리케이션이 session ID, 특히 취약한 웹 애플리케이션을 관리하는 방식의 한계를 탐색한다. 사용자 인증 시 새로운 session ID를 할당하지 않으므로(로그인 시 발급받은 세션 ID가 로그인 전/후 모두 동일하게 사용됨) 기존 session ID를 사용할 수 있으며, 공격은 유효한 session ID를 얻은 후 해당 세션 ID로 사용자를 인증하도록 유도하고, 사용된 session ID 를 알아내어..

💡 HTTP의 특성으로 인해 발생하는 문제... HTTP 프로토콜은 request를 전송한 후, response를 수신하게 되면 연결을 끊는 비연결성(Connectionless)의 특징과 request와 response에 대한 상태를 저장하지 않는 비상태성(Stateless)을 가지고 있기 때문에 로그인 인증이 정상적으로 수행되었다 하더라고 서버측에서는 사용자가 request를 수신할 때마다 인증된 사용자가 보낸 것인지 확인할 방법이 없다. 이러한 HTTP의 특성으로 인해 발생하는 문제를 해결하기 위한 방안으로 대표적인 것은 세션이다. 💡세션 기반 자격 증명 세션 기반 자격 증명 방식은 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식이다. 즉, 클라이언트 측에서 서버 측의 리소..

💡단위 테스트란? 애플리케이션의 일반적은 테스트 분류는 다음과 같다. - 기능 테스트 : 기능 테스트가 테스트의 범위가 가장 크다. 기능 테스트는 주로 애플리케이션을 사용하는 사용자 입장에서 애플리케이션이 제공하는 기능이 올바르게 동작하는지를 테스트한다. 기능 테스트를 하는 주체는 주로 해당 애플리케이션을 개발한 개발자가 될 수도 있지만 일반적으로틑 테스트 전문 부서 (QA부서) 또는 외부 QA 외부 업체가 됨. 종종 FrontEnd 개발자도 서버 측 애플리케이션이 잘 동작하는지 가볍게 테스트를 진행하기도 함. 기능 테스트의 경우 API 툴이나, 데이터베이스까지 연관되어 있어서 HTTP 통신도 해야 되고, 데이터베이스 연결도 해야 되는 등 우리가 개발한 애플리케이션과 연관된 대상이 많기 때문에 단위 테스..

데이터 액세스 계층은 서비스 계층에서 비즈니스 로직을 통해 처리된 데이터를 데이터베이스에 저장하고, 비즈니스 로직을 처리하기 위해 데이터베이스에서 데이터를 조회하는 등의 역할을 수행한다. 💡JDBC(Java Database Connectivity)란? Java 기반 애플리케이션의 코드 레벨에서 사용하는 데이터를 데이터베이스에 저장 및 업데이트 하거나 반대로 데이터베이스에 저장된 데이터를 Java 코드 레벨에서 사용할 수 있도록 해주는 Java에서 제공하는 표준 사양. Java 프로그램이 데이터베이스와 상호 작용할 수 있도록 하는 표준 Java API. Spring에서는 JDBC API를 직접적으로 사용하기 보다는 Spring Data JDBC나 Spring Data JPA같은 기술을 제공함으로써 개발자들..

샘플 애플리케이션을 구현해보면서 만날 수 있는 예외는 다음과 같다. 클라이언트 요청 데이터에 대한 유효성 검증(Validation)에서 발생하는 예외 서비스 계층의 비즈니스 로직에서 던져지는 의도된 예외 웹 애플리케이션 실행 중에 발생하는 예외(RuntimeException) DTO 유효성 검증 측에서 클라이언트의 요청 데이터 유효성 검증에 실패할 경우, 다음과 같은 응답 메시지를 확인 가능하다. 다음과 같은 Response Body 내용만으로는 요청 데이터 중에서 어떤 항목이 유효성 검증에 실패했는지 알 수 없다. 클라이언트 쪽에서 에러 메시지를 조금 더 구체적으로 친절하게 알 수 있도록 바꾸는 작업이 필요하다. 💡@ExceptionHandler를 이용한 Controller 레벨에서의 예외 처리 클라이..

💡DI(Dependency Injection) IoC라는 원칙을 구현하기 위해서 사용되는 방법 중 하나로, 용어를 있는 그대로 번역하면 `의존성 주입`입니다. 다음의 예시 코드를 보면 실제 MemberService라는 객체에서 MemberRepository라는 객체에 의존성을 가지고 있습니다. 또, 아래에 구현된 세가지 메서드들은 모두 MemberRepository객체에서 구현한 메서드를 사용하고 있습니다. 이러한 상황에서 MemberRepository라는 객체를 다른 MockRepository 객체로 교체해야 할 경우 어떤 일이 일어날까요? 실제로 private final MemberRepository memberRepository = new MockRepository();로 변경하면 될까요? 이렇게 ..

💡Framework vs Library Java Collection Framework은 자주 사용하는 자료구조를 바탕으로 데이터를 가공 및 처리하기 쉽도록 표준화된 방법을 제공하는 클래스의 집합이다. 즉, Framework는 기본적으로 프로그래밍을 하기 위한 어떠한 틀이나 구조를 제공한다. Framework를 사용하면 효율적으로 코드를 작성 가능하며, 정해진 규약이 있어서 애플리케이션을 효율적으로 관리 가능하다. 하지만, 자유롭고 유연한 개발이 어렵고, 사용하고자 하는 Framework에 대한 학습이 선행되어야 한다는 단점도 있다. Library는 애플리케이션을 개발할 때 사용되는 일련의 데이터 및 프로그래밍 코드를 말한다. 즉, 개발시 필요한 기능을 미리 구현해 높은 집합체로서, 개발자가 필요할 때마다..