이전 프로젝트는 현재 담당하고 있는 것 보다 규모가 훨씬 커서 테이블의 종류가 많았다. 그래서 다양한 테이블에 insert하는 매서드의 경우 중간에 오류가 발생하는 경우를 대비해 별도의 Exception을 정의하고 데이터 무결성을 위해서 rollback 처리를 반드시 해줬어야 했다. 그런데 현재 프로젝트로 넘어와서 코드를 확인해보니, @Transational 어노테이션만 붙이고, rollback은 따로 처리하지 않고 있었다. 지금 생각해보면 이유라기보다는 개발자의 미숙에 가까운게, 해당 프로젝트는 단 하나의 CustomException이 없었다. Checked Exception이 없기 때문에 굳이 rollbackfor를 정의할 필요가 없다는 생각이었을까? 정말 안전할지 알아보자. Transcational..
서비스 기획 중 하나가 카카오톡을 기반으로 서비스 예정이라, 이에 관한 마케팅을 진행한다고 한다. 그런데 현재 서비스가 카카오 로그인을 지원하지 않고 있었다. (사용자의 유입을 늘려야하는데!) 바로 구현에 들어가기로 했고, 카카오 Rest API 문서를 보면 Oauth 2.0 기반으로 회원가입/로그인을 지원한다고 한다. 그리고 아래와 같은 스퀀스 다이어그램을 하나 제공하는데... 이게 좀 문제가 있는게 SSR(서버 사이드 랜더링)을 위한 구조도이다. 그래서 CSR에서는 적합하지가 않다. 왜냐면 로그인 요청을 받은 서버에서 해당 사용자의 회원가입 여부를 확인해야하기 때문이다. 그리고 callback 페이지의 redirection도 해야하는데 서버에서는 적절하게 이를 제어할 수 없다. 때문에 FE 서버에서 ..
이전 글에서 SMS 본인 인증(엄밀히 말하면 휴대폰 인증)을 구현하는 법을 간단히 알아봤다. 하지만 문제는, 반복 요청에 대한 처리를 하지 않았는데 이 외에도 몇 가지 문제가 더 있다. 1. 이미 인증한 사람이 인증 번호 반복 요청 2. 아직 인증하지 않은 사람의 인증 번호 반복 요청 3. 인증한 사람이 다른 번호로 인증 번호 반복 요청 인증 번호를 요청하는 것은 단순하게 생각하면 FE에서 막아줄 수 있다. 문제는 새로고침 했을 때, 이 사람이 인증을 했거나 대기 중인 상태란 걸 내려 줄 수 있어야 한다. (그렇지 않으면 당연히 반복 요청을 할 수 있을 것이다) 방법은 여러가지가 있을 것 같다. user 테이블에서 sms_cert 와 같은 컬럼을 생성하고 , "Y", "N", "P"(pending) 값을..
현재 개발 중인 서비스에서 본인 인증 기능이 필요해졌다. 한번쯤 써봤을 PASS 본인인증 같은 기능이다. 내가 인증 대상이 될 때는 몰랐는데, 본인 인증 기능을 개발하려니 업체 선정에서부터 어려운 점이 생겼다. 결국은 요금이 가장 큰 걸림돌되었고,(현재 서비스는 사용량이 썩 많지 않다.) 우선 대표적인 국내 업체 두 곳을 비교했다. 구글링을 하면 가장 먼저 나오는 곳은 PASS와 드림시큐리티였다. 하지만 두 업체는 가장 먼저 후보군에서 제외 됐다. 두 곳 모두, 기본료가 청구된다는 것이다. 서비스 이용자가 많지 않아서 기본료가 청구되는 상황은 배보다 배꼽이 크다 판단했다. 또 SDK에 대한 정보가 하나도 없어서 구현 난이도나 주고 받는 정보가 우리 서비스에 맞을지 가늠이 잘 안됐다. (인증 UI까지 제공..
이전 글에선 JWT 검증 코드를 인터셉터에 적용해봤다. 이번 글에선 Filter에 적용해보자. 먼저 가볍게 Filter에 대해 짚고 넘어가보자. Filter는 Interceptor와 다르게 Dispatcher Servlet이 동작하기 이전에 위치한다. 그리고 별도의 필터에 대한 설정이 없으면 모든 요청에 대해서 반드시 한번 실행이 된다. 때문에 인터셉터보다는 더 범용적이고, 한번은 무조건 타야하는 보안, 인증/인가 작업이 주로 Filter에서 이뤄지게 된다. 흔히 알고 있는 스프링 시큐리티의 필터 체인들이 여기서 수행된다. Filter는 별도의 설정없이 Filter 인터페이스만 implements해도 요청이 들어올 때마다 실행되기 때문에 구현은 비교적 간단하다. 구현 여기서부터 등장할 jwt 관련 코드는..
이전 글에서 JWT가 무엇이고 어떤 데이터를 실어서 보낼 수 있나를 알아봤다. 그럼 이번 글부터는 어떻게 적용하면 될지 알아보자. 이번 글에서 소개할 방식은 interceptor에 적용하는 방식이다. interceptor는 스프링에서 제공하는 컨트롤러 이전에 위치하는 공통처리부 중 하나이다. 아래 그림을 확인하면 편하다. 공통처리부에 관한 글을 예전에 썼었는데, 이 때는 스프링 MVC를 쓰던 시절이라 필터와 인터셉터를 xml에서 제어를 하도록 구성되어 있었다. (왜 썼는지, 어떤 역할을 하는지 보다 이런게 있다라고 정리한 글이었다) 여기서 추가적으로 간단하게 짚고 넘어가면, Interceptor는 스프링 내부에서 Dispatcher Servlet 이후에 동작한다. 컨트롤러 앞단에 위치해 요청과 응답을 간..
오랜만에 글을 쓴다. 9월에도 다양한 작업을 했지만, 새 서비스 런칭을 준비하면서 인증관련 작업을 할 일이 생겼다. 세션을 써야할까 JWT를 써야할까 고민하다가, 앞으로의 확장성과 러닝커브 등의 이유로 JWT를 선택했다. (서비스가 언젠가 MSA로 확장될 가능성이 있었다.) JWT를 적용하기 위한 방법으로는 크게 두 가지가 있었다. 1. filter에 적용 2. interceptor에 적용 기존 서비스는 interceptor에 적용되어 있었고, 이번 서비스에서는 filter+스프링시큐리티를 적용해봤다. 각각의 방범의 장단점이 있는데, 이 부분들은 차차 정리하도록 하고 이번 글에선 JWT에 대해서 알아보려고 한다. 1. JWT란? JSON 웹 토큰 (JSON Web Token, JWT)은 선택적 서명 및 ..
아래는 한 서비스에서 쓰고 있는 application.yaml 파일이다. 위와 같이 길어진 이유는 서버의 종류가 엄청 많기 때문이다. 서버가 local/dev/stag/qa/prod 외에도 스케줄러가 붙어있어서 7~8개의 profile이 한 yml파일에 존재하게 됐다. 각각 서버의 profile은 아래와 같이 분리해서 application.yml 파일에 설정한다. ### ### ### local ### ### --- spring: config: activate: on-profile: local 나눠 놓을 수는 것 까지는 좋다. 그런데 관리를 제대로 하지 않았다. 그래서 모든 서버에서 공통적으로 사용하는 부분을 분리하지 않아서 yaml 파일이 엄청나게 길어지게 된 것이다. 이런 식으로 보관하면, 모든 서버..
- Total
- Today
- Yesterday
- serverless
- EKS
- lambda
- terraform
- openAI API
- 람다
- OpenAI
- 코딩테스트
- GIT
- docker
- Spring
- JWT
- S3
- AWS EC2
- cache
- java
- Kotlin
- Elastic cloud
- awskrug
- springboot
- AOP
- elasticsearch
- chat GPT
- CloudFront
- jenkins
- 스프링부트
- MySQL
- ChatGPT
- Log
- AWS
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |