이 글은 JWT, 액세스 토큰, 리프레시 토큰 등에 대한 개념적 정리이다. 목차 1. 개선 이전 상황 2. 액세스 토큰, 리프레시 토큰 정리 3. 구현 내용 4. 자체적인 질문과 응답 1. 개선 이전 상황 나는 JWT를 통해 인증&인가 관련 기능을 구현하였었지만, 액세스 토큰과 리프레시 토큰을 구분하지 않고 만료시간이 일주일 정도로 긴 하나의 토큰만 사용중이였다. 이를 개선해 본다. 2. 액세스 토큰, 리프레시 토큰 정리 개선 이전의 내 방식은 어떤 문제가 있을까? 1. 토큰 만료일이 일주일로 매우 길다. 2. 토큰 탈취시 강제 만료시킬 방법이 없다. 사용자가 매번 로그인을 해야하는 불편함을 없애기 위해 만료시간을 길게 하였지만, 토큰을 탈취당하면 긴 시간동안 악의적 행동에 시달려야 하며, 만료일 전까지..
이 글에서는 표준 예외와 사용자 정의 예외를 알아본다. 목차 1. 표준 예외, 사용자 정의 예외 2. 예외 선택 기준 표준 예외, 사용자 정의 예외 표준 예외: - 언어가 기본적으로 제공하는 예외 - IllegalArgumentException, IllegalStateException, NullPointerException... etc - 크게 3가지로 나뉜다. Exception - 검사 예외, checked Exception RuntimeException - 비검사 예외, unchecked Exception Error - 에러 장점 1. 사람들이 익숙함 2. 가독성, 유지보수성 좋음 사용자 정의 예외: - 사용자가 직접 정의하거나 표준 예외를 확장한 예외 - 예를들어, 은행 시스템에서 출금시 잔고가 모..
이 글은 정답이 아닌 개인적인 저의 생각 정리입니다...! . . . 고민 개발을 하다보면 계속 Controller와 Service의 역할에 대한 의문이 들었다. Controller가 Service에 있어야할 비즈니스 로직을 가지고 있게 된다고 생각했기때문이다. (내가 그렇게 했기때문에 그런거지만... ㅠㅠ) 실제로 내가 겪은 구체적인 상황: 어떤 컨트롤러의 post 요청에서 A,B,C 엔티티가 반드시 순서대로 생성된후 저장되어야 한다. (참조관계 때문에 그렇다) 기존에는 컨트롤러에서 A 엔티티 생성 -> AService.createA() 한 후 B, C도 동일한 과정을 거침. 이러니까 컨트롤러가 서비스의 역할을 해버린다고 생각함. 코드: //기존 코드 @PostMapping public Response..
테이블 구조를 변경하였다. 이미 저장된 데이터를 유지하면서 변경된 데이터를 옮기는 작업을 했다. 왜 바꿨냐면, 제3정규화를 위반하여 중복되는 데이터가 많을것으로 생각했기 때문이다. book 테이블은 회원이 고유하게 소유하는 책이다. 책 isbn, name 같은 정보 저장 말고도, 다 읽은, 읽는 중, 읽고싶은 등의 정보를 저장하고, 기획상 book이 post를 여러개 갖고 있어서 회원의 post들 테이블에 접근할때 처음 구분을 해주는 역할을 해준다. 구조 변경 전에 처음 설계할때는 사실 중복될것을 몰랐던건 아닌데, 같은 책 정보 몇개 들어온다고 크게 문제될까? 라고 생각했다. 어차피 별로 중복이 많을것같진 않은데 구조가 복잡해지는게 싫었다. 그런데 개발중에 쌓인 테스트 데이터를 보면서 생각해보니, 사실 ..
클래스 단위로 @Builder 사용시 필드를 전부 초기화 하지 않으면 예상하지 못한 일이 생길수도 있다. @Entity @Builder public class Book { @Id @GeneratedValue @Column(name = "book_id") private Long id; @Column(name = "book_name") private String name; @Column(name = "book_isbn") private String isbn; @Enumerated(EnumType.STRING) @Column(name = "book_category") private BookCategory category; @OneToMany(mappedBy = "book") private List posts ..
Servlet- 서블릿은 예전에 스프링같은 편리한 프레임워크를 사용하기전 사용했다고한다. 서블릿의 역할 서블릿은 프로그래머가 핵심적인 코드만 작성하도록 도와준다. 의미있는 비즈니스 로직 외에도 저런 수많은 작업을 처리해줘야 한다. 연결하고 파싱하고 연결끊고... 이런걸 전부 한땀한땀 하기에는 너무나도 힘들다. 난 대학에서 네트워크 시간에 http connection을 만들고 파싱하고 이런걸 해봐서 이 고통을 이해한다. 그게 싫었던 사람들은 서블릿을 만들어냈다. 스프링부트는 기본 내장 was로 톰켓을 사용한다. was로 http 요청이 들어오면 was는 response와 request 를 생성하여 서블릿컨테이너에서 싱글톤으로 관리되는 서블릿 객체에 넘겨준다. + 동시요청에 대비해 멀티쓰레딩을 이용해 서블릿..
출처: 자바 ORM 표준 JPA 프로그래밍 ㅇ 자주 쓸것같은것만 아주 간단하게 정리해보겠다. • 객체와 테이블 매핑: @Entity, @Table • 필드와 컬럼 매핑: @Column @Enumerated @Temporal @Lob @Transient • 기본 키 매핑: @Id @Entity 테이블과 매핑할 클래스에 사용. JPA 관리하에 두게함. 기본 생성자 필수. @Table (name = blabla)통해 테이블 이름 설정가능 @Column (name = blabla)통해 칼럼 이름 설정가능 insertable 옵션도 있음 @Enumerated EnumType.STRING으로 해야 나중에 대참사 예방가능 @Temporal :LocalDate, LocalDateTime 쓰면 안해도 괜찮음 @Lob 지..
출처: 자바 ORM 표준 JPA 프로그래밍 주된 이유: 패러다임의 불일치 . . . ===객체지향 언어와 관계형 데이터베이스의 차이에서 오는 어려움=== -객체를 테이블에 맞추어 모델링 해야함: 객체는 상속관계, 테이블은 슈퍼타입 서브타입 관계, 객체는 참조 사용, 테이블은 외래키 사용 -진정한 의미의 계층분할이 어려움: DAO 작성자와 service 작성자가 다를때, 서비스에서 DAO를 맘놓고 못쓴다. 쿼리가 실제로 어떻게 나가는지 일단 확인해야하기 때문이다. -객체를 자바 컬렉션처럼 디비에 저장하고 사용하고싶음: 그래야 다형성, 객체 그래프 탐색 등이 쉬움 종합하면, 프로그래머는 객체지향 프로그래밍의 장점을 살려서 프로그래밍 하고싶다. 그러나 패러다임의 불일치로 인해서 급한 불을 끄는 식으로 sql ..
