[Spring] Servlet "Filter" 현재 Controller에 의해서 매핑되는 Page가 다음 종류가 있다고 하자 1. 로그인 하지 않고 접근 가능 2. 로그인 해야 접근 가능 >> 여기서 과연 "로그인 해야 접근 가능한 페이지"가 진짜 로그인을 해야 cs-ssupport.tistory.com 이전에는 서블릿에서 제공해주는 "서블릿 필터"를 통해서 Request에 대한 필터링을 해주었다 이번에는 Spring에서 제공해주는 "스프링 인터셉터"를 알아보자 서블릿 필터 & 스프링 인터셉터 모두 웹과 관련된 "공통 관심 사항"을 처리하지만 적용되는 순서도 다르고 적용되는 방법또한 약간 다르다 Spring Interceptor Servlet Filter는 서블릿이 호출되기 전에 수문장 역할을 수행했지만..

현재 Controller에 의해서 매핑되는 Page가 다음 종류가 있다고 하자 1. 로그인 하지 않고 접근 가능 2. 로그인 해야 접근 가능 >> 여기서 과연 "로그인 해야 접근 가능한 페이지"가 진짜 로그인을 해야만 접근 가능한지 확인해보자 /members/1로 접근 결과로 알수있듯이 "로그인 후 전용 마이페이지"가 로그인을 하지 않은 사용자에게도 접근이 허용되고 있다 >> "URL"에 따라서 request를 필터링할 수 있게 도와주는 기능을 Servlet에서 제공해준다 : Servlet Filter Servlet Filter Servlet Filter는 Servlet이 제공해주는 "Request Filtering" 기능이고 일단 필터의 흐름부터 알아보자 Servlet Filter는 수문장 역할을 수행..

[Spring] Cookie HTTP는 Stateless한 프로토콜이므로 이전에 보낸 Request에 대해서 기억하지 못한다 이러한 Stateless한 특징을 해결하기 위해서 "쿠키"라는 개념을 활용한다 예를 들어서 로그인을 한다고 하자 어떤 사 cs-ssupport.tistory.com "쿠키"는 HTTP의 Stateless로 인해 탄생한 "유지를 위한 수단"이다 쿠키를 통해서 중요한 정보를 보관할 수 있고 쿠키를 통해서 Client & Server간에 인증을 간편하게 할 수 있었다 하지만 쿠키에는 여러가지 보안 이슈가 존재한다 가장 대표적인 보안 이슈는 쿠키에 Client의 중요 정보가 담길 수 있다는 것이다. 따라서 이러한 보안 이슈를 해결하려면 "중요한 정보들은 모두 서버에 저장"해야 하고 Cli..

HTTP는 Stateless한 프로토콜이므로 이전에 보낸 Request에 대해서 기억하지 못한다 이러한 Stateless한 특징을 해결하기 위해서 "쿠키"라는 개념을 활용한다 예를 들어서 로그인을 한다고 하자 어떤 사용자가 "A-1"라는 페이지에서 로그인을 하고나서 "A-2" 페이지로 이동하였다고 하자 stateless한 HTTP 특징에 의하면 A-2 페이지에서도 로그인을 유지하려면 query parameter를 통해서 로그인 정보를 유지해야 한다 여기서 이러한 상태 유지를 위해서 "쿠키"를 사용하는 것이다 Cookie 쿠키에는 2가지 종류가 존재한다 세션 쿠키 : 브라우저가 종료되면 사라지는 쿠키 영속 쿠키 : 브라우저가 종료되어도 "지정한 만료일"까지 유지되는 쿠키 기본적인 쿠키 로그인 테스트를 위해..

영속성 전이 : CASCADE 특정 엔티티를 "영속 상태"로 만들 때 → 연관된 엔티티도 함께 영속 상태로 만들고 싶다면 어떻게 해야할까 >> 영속성 전이 기능 (Transitive Persistence) JPA에서는 영속성 전이를 CASCADE 옵션을 통해서 제공한다 @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "member") public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "member_id") private Long id; private String name; @ManyToOne(f..

> "즉시 로딩 전략"을 활용하면 연관된 Entity도 DB에서 조회해서 실제 Entity가 반환된다 대부분의 JPA 구현체는 "즉시 로딩을 최적화"하기 위해서 가능하면 조인 쿼리를 사용한다 >> 위의 예제에서도 Member와 Team간의 left outer join을 통해서 쿼리 1번으로 연관된 두 엔티티를 모두 조회하였다 ※ 즉시로딩 & NULL 제약 조건 위의 조인을 잘 보면 "left outer join" : 외부조인을 통해서 Member과 Team이 조인을 하고 있다 현재 Member Table에서는 Team 컬럼에 대한 nullable을 허용하고 있는 상태이다 >> 따라서 Player중에 team이 없는 Player도 존재한다는 의미이다 그렇기 때문에 이 Member에 대한 instance도 ..

선수 Entity와 팀 Entity가 존재하고 서로 다대일 관계이다. Player (N) @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) @Entity @Table(name = "player") public class Player { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "player_id") private Long id; private String name; @ManyToOne @JoinColumn(name = "team_id") private Team team; } Team (1) @Getter @NoArgsConstructor(access = Access..

DB에서 두 테이블간에 관계를 나타낼때는 총 2가지로 분류할 수 있다 1. 상대방의 PK를 자신의 PK이자 FK로 사용 = 식별관계 2. 상대방의 PK를 자신의 FK로 사용 = 비식별관계 필수적 비식별 관계(Mandatory) : FK에 NULL 허용 X 선택적 비식별 관계(Optional) : FK에 NULL을 허용 O 비식별 관계 (복합키) 현재 PARENT Table은 PK가 "복합키"로 구성되어있는 상태이고 CHILD와 1:N 관계이다 따라서 CHILD는 PARENT의 PK : 복합키를 자신의 FK로 활용함으로써 둘의 관계는 비식별 관계이다 @Entity @Table(name = "parent") public class Parent { @Id @Column(name = "parent_id1") p..

[JPA] 상속 관계 일반적으로 관계형 DB에서는 객체지향 언어에서 다루는 "상속"이라는 개념이 존재하지 않는다 그대신 "슈퍼타입 - 서브타입"같은 모델링 기법을 통해서 우회적으로 상속을 구현할 수 있다 슈퍼 cs-ssupport.tistory.com 상속 관계의 기본적으로 JOINED 전략을 사용하면 Super Type & Sub Type 모두 DB Table과 매핑되었다 하지만 여기서 부모 클래스는 DB Table과 매핑하지 않고 자식 클래스에게 속성만 물려주고 싶다면 @MappedSuperClass를 사용하면 된다 @MappedSuperClass는 단순히 "필드 정보"를 상속할 목적으로만 사용하는 것이다 예를 들어서 거의 모든 테이블에 필요한 {생성 날짜 / 생성한 사람 / 수정 날짜 / 수정한 사..

일반적으로 관계형 DB에서는 객체지향 언어에서 다루는 "상속"이라는 개념이 존재하지 않는다 그대신 "슈퍼타입 - 서브타입"같은 모델링 기법을 통해서 우회적으로 상속을 구현할 수 있다 슈퍼타입 - 서브타입 논리적 모델을 실제 DB에 들어가는 물리적 모델로 구현하는 방법은 총 3가지가 존재한다 "각각 테이블"로 변환 "통합 테이블"로 변환 "서브타입 테이블"로 변환 1. 각각 테이블로 변환 - "조인 전략 (Super Type + Sub Type)" 조인 전략이란 엔티티 각각을 일단 모두 테이블로 만들어준다 그리고 "자식 테이블"은 부모 테이블의 PK를 자신의 PK이자 FK로 사용한다 조회할때는 당연히 Join을 많이 사용하게 된다 >> @Inheritance(strategy = InheritanceType..

[Spring] 검증(Validation) 1. 직접 구현하기 MVC 패턴에서 Controller는 request로 들어온 URL에 대한 처리도 하지만, HTTP Request 자체가 정상인지 "검증"하는 역할도 수행한다 물론 Front쪽에서 검증을 할 수 있지만, 이는 Client가 의도적인 조작을 통 cs-ssupport.tistory.com 앞에서 검증 기능을 직접 작성함으로써 객체에 대한 검증을 하였다 그런데 검증 기능을 매번 코드로 작성하려면 엄청난 시간과 노력을 투자해야 한다 그리고 대부분의 검증 로직은 {빈 값인지 아닌지 / 특정 크기를 넘는지 아닌지 / ...} 등 매우 일반적인 로직이다 이러한 검증 로직을 모든 프로젝트에 적용할 수 있게 공통화하고, 표준화 한 것이 바로 "Bean Val..

MVC 패턴에서 Controller는 request로 들어온 URL에 대한 처리도 하지만, HTTP Request 자체가 정상인지 "검증"하는 역할도 수행한다 물론 Front쪽에서 검증을 할 수 있지만, 이는 Client가 의도적인 조작을 통해서 우회해서 접근할 수 있기 때문에 Front쪽에서 1차 검증을 한 후, 2차적으로 Server에서 검증을 해야 한다 BindingResult BindingResult를 활용하면 request로 들어온 data에 대한 오류를 간단하게 담을 수 있고 model을 통해서 자동으로 넘겨줄 수 있다 BindingResult가 "없다면" 400 error가 발생하면서 컨트롤러 자체가 호출되지 않는다 반면에 BindingResult가 "있다면" 오류 정보를 BindingRes..