01 01

OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름과 같이 개념적인 부분을 서술한 문서입니다. OAuth 2.0은 클라이언트 또는 제 3자 애플리케이션이 사용자의 비밀번호를 직접 알지 않고도, 사용자를 대신해 정보에 접근할 수 있도록 권한을 위임하는 프로토콜입니다.e.g. 넷플릭스 계정을 구글 계정으로 로그인할 때 구글에 비밀번호를 입력하지만 넷플릭스는 구글 비밀번호를 모릅니다. 구글에서 인증된 사용자로 토큰Token을 발급해주면, 넷플릭스는 그 토큰 정보를 확인하고 로그인을 시켜줍니다.OAuth 2.0의 주요 컴포넌트Resource Owner, Client, Authorization Server, Resource Server Resource Owner(자원 소유) : ..

세션 기반 인증과 토큰 기반 인증의 차이점과 각각의 보안 고려사항에 대해 간단히 정리한 글입니다. HTTP 프로토콜은 Stateless 합니다. Stateless 하다는 건, 서버에게 가는 각각의 요청이 서로에게 영향을 끼치지 않고 독립적으로 이루어진다는 뜻입니다. 즉, 첫 번째 요청의 응답을 두 번째 요청과 공유하지 않는다는 거고, 이 말인즉슨 요청마다 우리가 누구인지 서버에게 알려줘야 한다는 것입니다. "서버에게 이 요청을 보낸 자가 누구인지 알려줌"을 할 때, 세션 기반 인증, 토큰 기반 인증 방법을 이용합니다. 세션 기반 인증KEYWORD : Session DB, Session ID, 쿠키 사용자가 로그인하면, 서버가 Session DB에 해당 유저의 Session ID를 생성하여 저장합니다...

docker-compose.yml 를 사용하는 멀티 컨테이너 애플리케이션을 간단히 설명하고, 왜 docker-compose.yml 을 쓰는 것이 용이한지, 그리고 어떻게 사용하는지에 대해서 작성한 문서입니다.  docker-compose.yml 를 사용하는 때 docker-compose.yml 은 멀티 컨테이너 애플리케이션을 정의하고 실행하기 위해 사용되는 도구입니다. 멀티 컨테이너 애플리케이션은 애플리케이션이 여러 개의 컨테이너로 구성된 경우를 말합니다. 예를 들어서 프론트엔드(nginx) + 백엔드(Spring Boot) + 데이터베이스(PostgreSQL) 과 같은 구성의 애플리케이션이 존재한다면, 각각 3개의 컨테이너로 실행하게 되어 멀티 컨테이너 애플리케이션으로 불리게 됩니다. docker-co..

테스트할 때 이용되는 Mockito의 간단 개념을 다른 Java Mock 라이브러리와 비교해서 설명하고, Mockito의 Mock, Stub, Spy 개념을 정리한 글입니다.  Mockito란?   Mockito는 모의 객체(Mock)을 만드는 라이브러리 중 하나입니다.Java Mocking 분야에는 EasyMock, jMock 같은 expect-run-verify(예상-실행-검증)방식을 따르는 라이브러리가 있습니다. EasyMock 은 expect 단계에서 "이 메소드는 n번 호출되어야 한다.", "이 메소드는 호출 후에 특정 값이 반환되어야 한다." 와 같은 예상안을 작성해두고, verify 단계에서 expect 단계에 작성해둔 예상안을 한 번에 검증합니다.반면 Mockito 는 expect 라는 개..

Index1. 입력값 검증(Input Validation) 이란?2. 입력값 검증을 각 계층별로 진행해야 하는 이유3. 중복 검증과 안전성의 트레이드 오프4. 계층별 검증 범위와 판단 기준이전에 작성한 데이터 검증(Vallidation)을 어디에서 해야하는가 와 같은 주제로, 추가적으로 필요한 정보를 보충하고 정리했습니다. 입력값 검증(Input Validation) 이란?프로그램에 입력된 데이터가 예상한 형식과 조건을 만족하는지 확인하는 과정입니다.  입력값 검증을 각 계층별로 진행해야 하는 이유단일 계층에서 입력값을 검증하기 보다 각 계층별마다 검증하는 것이 권장되는 이유는 다음과 같습니다. 데이터 분석 관점이 다르다 :각 계층은 하나의 데이터를 두고 다른 관점에서 분석합니다.때문에 검증해야할 항목이..

개발자 도구에서 Network 탭을 클릭한다.상단 필터에서 "XHR" 또는 "Fetch/XHR" 선택한다. (API 요청만 필터링)새로고침(F5 or Ctrl + R)하면 API 요청이 나온다.요청을 클릭하면 아래에 요청(Request) / 응답(Response) / 헤더(Headers) 등을 볼 수 있다.   Preserve log 체크하면 페이지 새로고침해도 로그 유지된다.Disable cache 체크하면 캐시 없이 매번 새 요청 보내기 가능하다.Filter에 api 같은 키워드 입력해서 원하는 요청만 찾을 수 있다.

트랜잭션의 ACID 속성 중 격리성(Isolation)에 대해서 간단하게 설명하고, 보장되지 않았을 때 발생할 수 있는 문제점과 이를 해결하기 위한 트랜잭션 격리 수준들을 제시합니다.   트랜잭션과 트랜잭션의 속성, 그리고 격리성(Isolation)트랜잭션은 데이터베이스에서 여러 작업을 하나의 단위로 묶어 처리하는 개념입니다. 트랜잭션의 속성 ACID는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 의미하고, 이 속성을 지키는 것은 트랜잭션의 신뢰성을 높입니다.그중 격리성(Isolation)은 동시에 실행되는 트랜잭션이 서로 간섭하지 않도록 보장하는 것으로 트랜잭션이 독립적으로 실행되도록 해 데이터의 일관성을 유지하도록 합니다. A..

JPA에서 발생하는 N+1 문제, 그리고 해결 방안에 대해 정리한 문서입니다. N+1 문제란?데이터베이스와 객체 관계 매핑(ORM)을 사용할 때 자주 발생하는 성능 이슈로, 특정 엔티티를 조회(1)할 때, 해당 엔티티와 연관된 다른 엔티티를 (N)번 쿼리로 추가적으로 조회하는 상황을 말합니다. 해당 문제는 로딩 전략(EAGER Loading, LAZY Loading)에 상관없이 발생합니다. 즉, 연관 관계가 있는 엔티티에 접근할 때 추가 쿼리가 발생하는 패턴일 때, N+1 문제가 발생한다고 생각하면 됩니다.  EAGER Loading, LAZY Loading과 N+1 문제더보기EAGER Loading(즉시 로딩)엔티티를 로드할 때 연관된 엔티티도 함께 로드합니다.@ManyToOne과 @OneToOne 관..