TIL-19

카카오 로그인 구현과 JPA 공부한날이다.

 

Kakao Developers

카카오 로그인은 공식 문서 보는게 제일 정확하다. 언제 바뀔지도 모른다.

 

카카오 사용자 토큰 발급 (2020/04 변경사항 update)

 

나는 두개의 링크를 더 참고했다. 하나는 검색해서 나온 거고 하나는 옛날에 따라치던 클론코딩이다.

 

생각해야 될 것이 몇가지 있는데 원래 우리는 토큰 방식의 로그인을 썼고 

아래와 같이 테이블을 짰다. 

만약 우리 홈페이지에 자체 로그인을 한다면 회원가입 폼 입력을 강제하면 되지만 카카오 로그인은 우리가 접근할 수 있는 정보가 매우 제한돼있다. 이메일도 선택이고 식별 가능한 아이디와 닉네임만 받을 수 있다. 아직은 마이페이지가 완성되지 않아서 바로 연결을 못하지만 한솔님이 마이페이지를 완성해서 올려주시면 카카오 로그인을 통한 리다이렉션은 마이페이지로 가게 만들어서 블로그 주소를 입력을 장려하는 방향이 나을 것 같다.

 

또. 한 컨트롤러에 두번의 request를 다 넣어놓은게 마음에 걸린다. 안된다는걸 알면서도 우선 구현이 먼저기 때문에 그렇게 했다. 나중에..나중에..

카카오 로그인은 위와 같은 워크 플로우만 이해하면 된다. 기존 토큰방식의 로그인은 우리가 서버고 사용자가 클라이언트여서 우리에게 요청을 하는 입장이었다면 카카오 로그인을 하는 사용자 입장에서는 본인이 리소스 오너, 내 웹페이지가 클라이언트, 카카오 API 서버는 인증 서버, 자원서버는 리소스 서버라고 생각하면 된다.

 

토큰을 발급받는 kauth서버가 인증서버

토큰을 이용한 데이터를 요청하는 kapi서버가 리소스 서버다. 총 두번의 요청이 필요하다.

 

카카오 로그인에 대한 비밀번호는 임의의 값을 암호화 해주는 방법을 사옹했는데 이렇게 해도 되는지에 대한 의문은 있다. 내일 튜터님한테 여쭤봐야겠다.

 

아무튼 그렇게 해서 우리 db에 id와 닉네임을 넣고 임의의 비밀번호까지 넣어서 토큰 인증까지는 가능한 상태다. 

그리고 http 공부가 더 필요하다는 생각이 들었다. 에러코드를 보고 이유를 바로 생각해볼 수 있는 수준까지.

 

지난번에 튜터님이 s3와 서버를 따로 쓰는 이유가 뭘까요? 라고 하셨는데 이유를 찾아봤다.

s3는 imple storage service의 약자로 파일 서버의 역할을 하는 서비스다. 파일서버의 트래픽 증가에 대응하기 위해서는 장비를 증설해야 되는데 s3를 늘림으로써 대응 가능하게 한다. 또, 각 파일에 대한 접근 권한 설정이 가능해 서비스를 호스팅 용도로 사용하는 것을 방지한다.

일반적인 파일 시스템과는 다른 key와 파일로 구분되는 객체 스토리지다. 객체들의 변화를 저장하기 떄문에 실수를 만회할 수 있다.

 

JPA

어제 했던 임베디드 타입의 연장이다. 

@Embeddable과 @Embedded에 대해 알아보자

table을 짤 때

다음과 같이 객체가 만들어져 있다면 막 그냥 묶고 싶어서 안달이 날 것이다.

 

그 때 필요한게 임베디드 타입이다.

 

@Entity
public class Member extends BaseEntity{

    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @Column(name = "USERNAME")
    private String username;

    @Embedded
    private Period workPeriod;
    
    @Embedded
    private Address homeAddress

workPeriod 객체에서는 @Embeddable을 달아주고 부모에서 Embedded를 달아주면 된다. 원래는 둘 중 하나만 넣어도 되지만 가시성을 위해. 이러면 JPA에서 Member 테이블을 만들 때 알아서 workPeriod와 homeAddress의 변수들까지 table로 만들어 준다.

 

임베디드 타입의 장점

-임베디드 타입은 엔티티의 값일 뿐이다.

-사용하기 전과 후 매핑하는 테이블은 같다.

-객체와 테이블의 세밀한 매핑이 용이하다.

-잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.

 

@Embedded
private Address homeAddress;
    
@Embedded
private Address workAddress;

다음과 같이 한 엔티티에서 같은 값 타입을 사용하면 컬럼 명이 중복되기 때문에 

여러개면 @AttributeOverrides, 한개면 @AttributeOverride를 사용해서 컬럼 명 속성을 재정의 하면 된다.

 

값 타입과 불변 객체

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다.

 

            Address address = new Address("city", "street", "10000");

            Member member1 = new Member();
            member1.setUserName("member1");
            member1.setHomeAddress(address);
            em.persist(member1);


	//Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());
			
            Member member2 = new Member();
            member2.setUserName("member2");
            member2.setHomeAddress(address);
            em.persist(member2);
            
            member.getHomeAddress().setCity("newCity");

실제로 코드를 이렇게 쓰면 db에서는 두 멤버 다 주소가 newCity로 출력된다.

값 타입을 직접 복사하는 것을 위험하다. 인스턴스를 복사해서 사용해야 한다.

주석처럼 해야 된다는 것이다. 하지만 이것도 문제점이 있다.

1. 항상 값을 복사해서 사용하면 공유참조로 인해 발생하는 부작용은 피할 수 있지만 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다. 기본은 복사라는 것이다.

2. 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없기 떄문에 결론적으로 근본적으로 객체의 공유 참조를 피할 수 없다.

 

 

따라서, 객체 타입을 수정할 수 없게 불변 객체로 설계해야 한다.(생성 시점 이후에 값을 변경할 수 없게 만든 객체)

생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 된다.