분류 전체보기

Oauth 카카오 로그인 + Spring Boot + JWT 로그인 구현(2)

지난 글에서 Jwt AccessToken, RefreshToken을 발급받는 과정까지 구현해 보았다 발행된 AccessToken의 값은 무조건적으로 명백하다고 생각하여 요청을 허가시킴. Access Token탈취의 위험이 존재하기 때문에 짧은 유효시간을 두어, Access Token이 탈취 당하더라도 만료되어 사용할 수 없도록 한다. Refresh Token은 서버에서 그 값(Redis)을 저장함. Refresh Token을 사용할 상황이 오면 반드시 서버에서 그 유효성을 판별, 유효하지 않는 경우라면 요청을 거부. 혹은 사용자로부터 탈취됐다는 정보가 오면 그 Refrsh Token을 폐기할 수 있도록 설정. 위 과정에서 Redis를 사용하는 이유는 다음과 같다. Refresh Token을 서버에서 어디..

Github label 커스텀 적용하기

Github label 커스텀하여 적용하기 깃허브 issue , pull request 작성을 위해 label을 커스텀 하여 사용하기로 했다. 최종적으로 위와 같이 바뀔것이다. ✅ Github Label github label은 issue와 pull request에서 카테고리를 분류하기 위한 이름표로 사용된다. ✅ gitHub 라벨 적용 원하는 경로에 labels.json 파일을 만들어준다. labels.json에 다음과 같이 설정해준다 ``` [ { "name": "⚙ Setting", "color": "e3dede", "description": "개발 환경 세팅" }, { "name": "✨ Feature", "color": "a2eeef", "description": "기능 개발" }, { "nam..

Oauth 카카오 로그인 + Spring Boot + JWT 로그인 구현(1)

Oauth(Open Authorization)란? Oauth는 인증을 위한 프로토콜이다. 다른 인터넷 서비스의 기능을 다른 애플리케이션에서도 사용할 수 있게 해 준다. OAuth 인증도 제공하지만, 주요 목적은 인증된 사용자에게 사용자의 이름이나, 이메일을 가져온다든지 하는 권한을 제공해주는 것이다. 우선 필자의 경우 프론트엔드 개발자와 협업을 하기 때문에 Authorization Code Grant 방식으로 진행할 것이다. Oauth 서버에서 client application에게 바로 access token을 넘겨주는 것이 아니라, Authorization code를 넘겨주고, client Application은 Authorization code를 통해 access token을 발급받아, access ..

객체지향 쿼리 언어

JPA는 다양한 쿼리 방법을 지원한다. JPQL JPA criteria QueryDSL 네이티브 SQL JDBC 직접 사용, Mybatis, SpringJDBCTemplate 함께 사용 JPQL JPA를 사용하면 엔티티 객체를 중심으로 개발한다. 문제는 검색 쿼리이다. 검색을 할 때도 테이블이 아닌 엔티티 객체를 대상으로 검색한다. 모든 DB 데이터를 객체로 변환해서 검색하는 것은 불가능하다. 애플리케이션이 필요한 데이터만 DB에서 불러오려면 결국 검색 조건이 포함된 SQL이 필요하다. JPQL이란? JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어를 제공한다. SQL과 문법이 유사하며, SELECT, FROM, WHERE, GROUP BY, HAVING JOIN을 지원한다. JPQL은 엔티..

값 타입

JPA의 테이터 타입 분류 엔티티 타입 - @Entity로 정의하는 객체 - 데이터가 변해도 식별자로 지속해서 추적 가능 값 타입 - int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체 - 식별자가 없고 값만 있으므로 변경 시 추적 불가 값 타입 분류 - 기본값 타입 생명주기를 엔티티에 의존 값 타입은 공유하면 안 됨 - 임베디드 타입 새로운 값 타입을 직접 정의할 수 있음 JPA는 임베디드 타입이라 함 주로 기본값 타입을 모아서 만들어서 복합 값 타입이라고도 함 int, String과 같은 값 타입 임베디드 타입 사용법 @Embeddable : 값 타입을 정의하는 곳에 표시 @Embedded : 값 타입을 사용하는 곳에 표시 기본 생성자 필수 임베디드 타입의 장점 ..

프록시, 즉시 로딩과 지연 로딩

Proxy - em.getReference() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회한다. - em.find() : 데이터베이스를 통해서 실제 엔티티 객체를 조회한다. getReference를 호출하는 시점에는 쿼리가 나가지않고, 이 값이 실제로 사용되는 시점에 쿼리가 나가게 된다. 위의 코드를 해석해 보자면 em.getReFerence로 Member클래스를 상속받고 있는 프록시 객체를 생성하게 되고, 이 생성된 프록시객체는 findMember.getUsername()처럼 실제로 사용하는 요청이들어올때 영속성 콘텍스트로부터 초기화 요청을 보내게 된다. 영속성컨텍스트는 실제 Member엔티티를 생성하게 되고 프록시는 타깃으로 엔티티를 참조하게 된다. 하이버네이트가 강제로 만든 가짜 ..

고급 매핑

상속관계 매핑 관계형 데이터베이스는 상속 관계가 없다. 슈퍼 타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사하다 상속관계 매핑 : 객체의 상속과 구조와 DB의 슈퍼 타입 서브타입 관계를 매핑 슈퍼 타입 서브타입 논리 모델을 실제 물리 모델로 구현하는 방법은 다음과 같다. 1. 각각 테이블로 변환 -> 조인 전략 2. 통합 테이블로 변환 -> 단일 테이블 전략 3. 서브타입 테이블로 변환 -> 구현 클래스마다 테이블 전략 일반적으로 클래스에서 상속을 받은 객체들로 매핑을 하게 되면 하나의 테이블에 모든 컬럼이 생기게 된다. 여기서 부모 클래스에 아래의 코드와 같이 어노테이션을 추가하면 조인 전략으로 테이블을 설계할 수 있다. 조인 전략 위의 DB의 테이블을 보면 단일 테이블 전략 같은 경우 ITEM..

다양한 연관관계 매핑

연관관계 매핑 시 고려사항 - 다중성 - 단방향, 양방향 - 연관관계 주인 N : 1 위의 코드를 보면 @ManyToOne으로 N:1의 관계로 매핑되어있다. 즉 이 엔티티는 연관관계의 주인이자 TEAM_ID의 외래 키를 가지고 있는 엔티티이다. 그리고 그 반대로 @OneToMany로 서로 대칭으로 이루어져 있는데, 이 엔티티는 연관관계의 주인이 아니다. 따라서 mappedBy로 연관관계의 주인의 변수를 참조하고 이 엔티티는 읽기 전용이 된다. 1:1 관계 일대일 관계는 그 반대도 일대일 주 테이블이나 대상 테이블 중에 외래 키 선택 가능 - 주 테이블에 외래 키 - 대상 테이블에 외래 키 외래 키에 데이터베이스 유니크 제약조건 추가 위의 코드를 보면 OneToOne 관계인데 1:N 관계의 양방향 연관관계..