개발과 일상

핸드폰 SMS 인증을 개발하면서 해외의 SMS 서비스를 사용하면서 핸드폰 번호 포맷 변환 기능이 필요하게 되었다. Twilio에서는 E.164이라는 핸드폰 번호 국제 표준을 사용한다. 해외 서비스를 이용하면서 SMS 인증을 해본 사람들은 한번씩 다 봤을 번호 체계이다. E.164 format 이란? 우리나라의 country code는 +82 이다. 그리고 우리나라의 핸드폰 번호는 대부분 010 - xxxx - xxxx 이다. 이 번호들을 기준으로 E.164 format으로 핸드폰 번호를 변경하면 +8210xxxxxxxx 이 된다. 그런데 문제는 오래된 번호 사용자들은 010이 아닐수도 있고 11자리가 아닐수도 있다. 이걸 하나씩 하드코딩할 수는 없어서 괜찮은 라이브러리가 있어서 소개해보려고 한다. lib..

10월 두번째 스프린트로 진행한 미니프로젝트에서 발생한 일. 목요일 상용 서버 배포를 진행하고 테스트를 충분히한 후에, 마음 놓고 퇴근했다. 다음날 10월 20일 금요일 여유있게 출근하고, 아침 9시경 별 생각없이 어제 배포된게 잘 돌고 있나 테스트를 진행해봤다. 슬프게도 먹통이었다. dev서버와 qa서버에서 동일한 현상이 나타나는 걸 확인하고, 로컬에서 바로 테스트를 진행 다행히 바로 어떤 문제 상황인지 확인이 됐다. feign.FeignException$InternalServerError: [500 Internal Server Error] during [POST] to [https://api.openai.com/v1/embeddings] [OpenAiFeignClient#createEmbedding(..

Thirdparty cookie를 처리하면서 발생한 문제. BE 도메인 : api.[메인 도메인 주소].com FE 도메인 : web.[메인 도메인 주소].com 도메인 주소의 전체 이름은 다르지만 하위 도메인 주소를 뺀 부분이 같다. 떄문에 별 생각 없이 쿠키의 도메인을 [메인 도메인 주소].com으로 지정해줬다. 이럴 경우 web.[메인 도메인 주소].com에서 해당 쿠키를 확인할 수 없다. 하위 도메인에서 쿠키를 확인할 수 있도록 해야하기 때문에, "."을 반드시 포함시켜서 .[메인 도메인 주소].com 으로 지정해줘야 한다. 작업할 당시에는 쿠키에 별 생각 없이 아래와 같이 도메인을 붙였다. public Cookie setCookie(String guestId) { int maxAge = 24 *..

이번 주에 발생했던 따끈따끈한 문제 문제 상황은 이렇다. 1. 비로그인 사용자를 구분하기 위한 id를 부여하고 싶다. 2. id를 어디서 부여하고 저장할까? - 보안상의 이유로 단순 로컬스토리지보다는 쿠키에 저장하는 게 좋을 것 같다. 3. 누가 쿠키를 발행할 것인가? fe가 가능할 것 같다고해서 별 생각 없이 ok 4. fe 서버에서 쿠키에 강제로 domain을 부여하니까 localhost에서 쿠키를 사용할 수 없는 문제 발생 5. 결국 서버에서 쿠키를 만들기로 하는데.... 결론부터 이야기하자면 모두가 쿠키에 대한 제대로된 지식이 없어서 발생한 문제였다. 정확히는 Thirdparty cookie와 cookie의 도메인에 대한 지식이 부족했다. 어떤 문제가 발생했는지 차근 차근 밟아나가보자. 이슈 1...

해당 기능을 쓰기 위해서는 GPT 유료 버전을 사용해야 합니다. 기존에도 GPT는 이미지 생성하는 API를 제공하긴 했었다. /v1/images/generations API로 제공했었고, 이 내용은 여기에서 확인해 볼 수 있다. 그런데 9월 말(관련 기사)에 DALL E 3를 Chat GPT에서 사용할 수 있게 되었다. chatGPT는 유료버전을 사용할 때, 2023년 11월 업데이트 이후로 DALLE 4를 지원합니다. 이미지 생성 방법은 간단하다. 그냥 GPT에 "이미지를 그려줘"라는 뉘앙스를 담아서(2024.1.12일 추가) 질문하듯이 질문을 하면 된다. 아래부터는 DALLE 3를 썼을 때입니다. 2023년 11월 이전에 질문한 결과 이지만 질문 방식은 지금과 동일합니다. 다양한 화풍의 이미지를 생성..

이전 글에선 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)은 선택적 서명 및 ..