개요 프로젝트를 진행하면서, 자연스럽게, 사용자 보안 인증에 대해 관심이 가게 되었다. 기본적으로 블로깅을 해보니, 인증 방식은 대부분 JWT 혹은 form으로 아이디/비밀번호를 받아, 세션ID를 쿠키에 저장하는 방식이다. 둘 중에 하나를 선택하면 될 것 같았지만, 세션 ID를 쿠키에 저장하자니, 앱 환경에서는 인증이 어려운 상황이고, JWT의 경우는 세션 서버를 따로 운영할 필요가 없지만, 토큰에 인증정보를 포함하면서, 생기는 보안의 취약점이 신경 쓰였다. 그래서 결국엔 세션ID를 Token에 포함하여, 인증을 세션 서버를 통해, 비교적 안전하게 진행하는 방식을 채택하기로 했다. 인증 방식의 종류와 차이점 자세한 내용은 이전에 정리했던 문서를 참고해보면 좋다. https://postwithmemory...

Security 인증방식 개요 security를 직접 적용하고 사용하기 전에, 인증방식의 종류와 선택의 기준을 확고히 하기 위해 이 문서를 작성함. 인증(Authentication)이란? Who are you? 보편적으로는 아이디, 비밀번호를 입력하여 사용자를 확인하는 과정을 말한다. API의 경우 호출하는 대상을 확인하는 절차가 필요하다. Session Session 이란? 일반적으로 사용자가 인증을 하기위해 아이디/비밀번호를 입력하면, 서버는 Session DB는 해당 사용자 Session을 생성한다. Session에는 별도의 ID가 있다. 웹 브라우저에서는 일반적으로, Session ID를 쿠키로 저장하여, 인증이 필요한 리소스에 요청을 할 때마다, Session ID의 쿠키 값을 이용한다. Tok..

개요 F-LAB에 소속된 멘토님의 리뷰를 받아가며, 한참 애플리케이션을 개발하던 중, 예외처리를 하는 것이 생각보다 간단하지 않다는 것을 알게 되었다. 물론 예외 메세지를 api에 전달하는 것 자체는 JSR-303 validation api의 도움을 받는다면, 매우 간단하다. 특히, 뷰 렌더링을 서버에서 처리하는 SSR 방식의 개발은, BindingResult와 같이 사용하여, Validator를 좀더 다채롭게 사용할 수 있다. 하지만, HTTP api로 개발을 해야하는 경우, @ModelAttribute와 달리 메세지 컨버터로 메세지를 리턴해야할 경우, 검증 위반 필드 목록을 불러오려면, 인위적으로 코드를 건들여야 했고, 그러다 보면, 불필요하다 싶을 정도로 반복되는 코드가 발생하는 경우가 많았다. 특..

개요 그동안 프로젝트 작업을 하면서, 여러 종류의 에러를 받고 디버깅 작업을 해왔다. 당연히 출시를 하기 전에는 에러를 고쳐야하는 것이 맞지만, 열심히 고치고 고쳐서 출시를 하여도, 여러가지의 원인으로 에러가 발생한다. 에러를 알리고, 해결방안을 제시하는 방법은 매우 다양하고, 사실 표준 스펙도 없다. 다만, 지금과 같이 협업 프로젝트를 진행해야하 하는 경우, 혼란을 피하기 위해선, 어느정도 일관적인 기준이 필요하다고 판단을 하게 되었다. 이번 일지는 내외부에서 api를 사용하는 개발자의 실수(혹은 서버의 문제로)로 발생하는 버그를 좀더 효율적으로 다룰 수 있도록 하는 목적을 가진 '에러 메세지'를 어떻게 다루느냐에 대한 나의 고민과 특정 결과물을 만들게 된 과정을 서술해볼 까 한다. IN..

작업 일지#3 카테고리 도메인의 기능 구현 그리고, 상품 도메인과 연계 개요 최근에 정신이 없었다. 화이자 2차 백신을 맞고 한동안 몸이 계속 안좋았다. 살면서, 이렇게 앓아누우면서 고생했던 건 이번이 거의 처음인듯 했다. 그동안 개발 공부한다고, 무리해서 쌓였던 피로도와 2차 백신의 부작용이 큰 원인인 듯 했다. 그래서, 살기위해(?) 한동안 휴식에 전념했던 것 같다. 지금은 컨디션이 매우 좋아져서 다시 개발공부에 전념할 수 있어, 카테고리 도메인 관련 작업을 진행했고, 이렇게 다시 작업일지를 작성할 수 있었다. 본론으로 돌아와서, 이번엔 상품 도메인의 단순 상품 CRUD 기능에 카테고리를 더하여, 좀더 상품을 다채롭게(?) 다룰 수 있는 기능을 구현하고자 했다. 카테고리 도메인을 작업하면서 가장 어려..

개요 작업일지#1 도메인을 짜보자 - 상품 도메인 설계를 기반으로 설계한 Item entity를 바탕으로 기본적인 CRUD 비즈니스 로직을 구현하기로 했다. 여기서 CRUD는 Create, Read, Update, Delete 이 네 단어의 앞글자만 붙인 용어로, 데이터의 기본 성질을 표현할 때 많이 사용하는 단어이고, entity는 도메인 주도 설계에서 ID를 통해 객체를 구분하며, mutable한 튿징을 가진 plain object이다. '토비의 스프링'에 따르면, 스프링은 다음과 같은 3계층 아키텍처에 적합한 프레임워크라고 한다. 프레젠테이션 웹, UI (controller) 서비스 비즈니스 로직 (Service) 데이터 액세스 DAO 계층 (Repository) 이번 프로젝트에는 이 계층에 완전히..