전체 글196 JWT 이대로 괜찮은가? 인증 / 인가에 JWT를 사용하여 구현하는 경우가 상당히 많다. JWT를 사용하는 이유는 Stateful해서 서버에 부하가 걸릴 수 있는 세션과 달리 Stateless하며, 중요한 식별값(아이디, 비밀번호 등)이 그대로 넘어가는 쿠키에 비해 안전하다는 것이다. 그런데 순수하게 Stateless한 JWT를 사용하는 것이 과연 옳은가? 이 부분에 대해서 의구심이 든다. Stateless하다는 것은 달리 말하면 서버가 해당 토큰에 대해 모른다는 것이다. 즉, 토큰을 사용한 공격에는 취약한 점이 있다. 동시에, 로그아웃을 명확히 구현해내기 굉장히 어렵다. 가장 널리 알려진 경우가 다중 로그인일 것이다. 순수 JWT를 사용하면 한 계정으로 여러 번 로그인 하는 것을 막을 수 없다. 그렇다고 이미 로그인한 사용자의.. 2024. 1. 2. Pull Request 026. 자유 게시글 테스트 코드를 리팩토링하며 느낀 점 자유 게시글에 헥사고날 아키텍처를 적용하면서, 많은 클래스의 변동이 일어났다. 이에 맞춰 테스트 코드도 리팩토링해야 한다. 크게 달라진 것은 없다. 로직 자체가 많이 바뀌지 않았기 때문에, 테스트 코드 작성도 전과 비슷한 맥락에서 진행되었다. 그럼에도 가장 크게 느낀 점 몇 가지를 기록해보고자 한다. 먼저, DTO를 많이 사용하는만큼 테스트 코드의 길이가 길어졌다. 기존에는 하나의 DTO를 여러 계층에서 사용했기 때문에 테스트 코드에서도 많게는 2개, 적게는 1개 정도의 DTO만을 만들어서 사용했다. 그러나 Client -> API / API -> Client / API -> Application / Application -> API / Application -> Persistenct / Persist.. 2023. 12. 29. [12/26 TIS] 혹시 이 글을 보고 계신다면 제발 도와주세요. 문제는 댓글의 API DTO에서 발생했다. 댓글을 등록하는 API DTO는 아래와 같은 구조로 생겼었다. public final class CommentApiDto { @Getter @Builder public final static class Post { private final String content; } } 이 구조는 자유 게시글 등록 API DTO를 고대로 가져온 것이다. 해당 클래스도 살펴보자. public final class FreeBoardApiDto { @Getter @Builder public final static class Post { private final String title; private final String content; } } 필드가 한 개냐, 두 개냐의 차이일.. 2023. 12. 27. Pull Request 025. 회원 도메인을 향한 의존은 어디에 존재해야 할까? - 게시글 수정 기능 리팩토링 헥사고날 아키텍처로의 시스템 아키텍처 전환을 프로젝트에 적용하면서, 가장 어려우면서 동시에 가장 중요하게 처리해야한다고 느낀 부분은 다른 도메인과 회원 도메인 간의 연관관계다. 현재 프로젝트에서는 크게 게시글, 바버샵, 예약, 채팅, 회원의 도메인이 나온다. 회원 도메인은 발생할 수 있는 모든 유즈케이스의 주체다. 따라서 나머지 세 개의 모든 도메인과 연관되어있다. 결국, 가장 중요한 도메인은 회원이 된다. 그래서 회원은 독립적으로 존재시키는 것이 좋다. 다른 도메인과 연관관계를 맺는 순간 다른 도메인의 복잡도가 회원에 전파된다. 그럼 다른 도메인은 회원에 어떻게 의존해야할까. 이 고민을 시작한 것은 게시글 수정 기능을 리팩토링하면서다. 게시글을 수정하기 위해서는 게시글의 작성자와 수정 요청을 보낸 사용.. 2023. 12. 18. Pull Request 024. 아키텍처 리팩토링 및 패키징 수정 - 자유 게시글 등록 기능에 헥사고날 아키텍처 적용하기 진행하고 있는 프로젝트는 지금까지 전형적인 3티어 아키텍처를 적용하였다. 그러나 사실상 애플리케이션 레이어에 모든 기능이 몰아져 지나치게 해당 레이어가 비대해졌다. 더 큰 문제는 이게 3티어 아키텍처인지를 표현하지 못하는 패키징 방식을 사용하고 있었다는 것인데, 이를 해결하고 시스템 복잡도를 제어하기 위한 더 나은 방향성을 지향하기 위해 헥사고날 아키텍처를 적용해보고자 한다. 먼저 기존의 패키징 방식을 살펴보자. 하나의 도메인 영역 내에 계층 구분이 명확하게 되어있지 않다, controller와 repository가 같은 단위에 자리하고 있다. 특정 계층에서 역할을 수행하는 객체를 찾기가 쉽지 않다, dto의 사용 위치나 entity의 사용 위치를 파악하기 어렵다. 아래는 아키텍처를 적용하고 패키지를 수.. 2023. 12. 15. 계층별로 분리해서 DTO를 사용하기로 한 이유와 결과 우리는 DTO를 통해 각 계층별 데이터의 전송을 수행한다. 클라이언트에서 서버로 보내는 정보를 JSON 데이터 타입으로 활용하기 위해 DTO를 사용하기도 하고, API 계층에서 애플리케이션 계층으로 정보를 넘겨줄 때 DTO를 사용하기도 한다. 아니면, 클라이언트에서 서버로 보내준 DTO를 그대로 애플리케이션 계층까지 내리는 경우도 있다. 이번에 헥사고날 아키텍처를 프로젝트에 적용해보는 시도를 하면서, DTO에 대해 고민해봤고 그 생각을 좀 정리해보고자 한다. DTO의 역할 위에서는 언급하지 않았지만, DTO의 역할과 책임에 대해서도 DTO는 Data Transfer Object의 줄임말이다. 말 그대로 '데이터를 전송하는 객체'다. 즉, DTO가 지닌 책임은 데이터의 전송이다. 그런 DTO에게 데이터의 .. 2023. 12. 13. 이전 1 2 3 4 5 6 7 8 ··· 33 다음 반응형
