Youngble_개발스토리

로그인기능을 구현할때 쿠키사용시에는 보안관련해서 secure, httponly, csrf.disable, samesite=strict 등 기본 설정이 필요한데이를위해서 기존에 들었던 XSS와 CSRF가 무엇인지 제대로 공부하게되었다. 먼저 세션기반(쿠키사용)으로 관리할지 JWT 토큰기반으로 관리할지 고민하다가 세션기반의 경우는 서버가 직접관리하면서도 확장성(여러 서버가 생긴다면)이를 통합해야하는 개념과 서버에 과부화가 걸릴수도있는 문제등을 생각했을때 해보고싶은 경험도 중요했지만 이부분은 프리티어 기준으로 너무 신경쓰다보면 꼬일거같아서 과부화와 확장성을위해 좀더 편하게 관리하기위해 JWT 기반으로 사용하기로했다. JWT를 사용한다면 보통 access token과 refresh token을 사용하게 되는데,..

HTTPS의 ssl/tls이 어떻게 동작하는지 원리를 알고싶어서 공부하게되었다. 사실 EC2가 아니더래오 어덯게 동작하는지 알면좋다고생각했다. HTTP와 HTTPS는 무엇이 다르고 HTTPS는 뭐였지? -> Https는 secure이니 http에 보안을 더한거지-> 그래서 무슨 보안을 더한건데? 보안넣고 통신하는거랑 안하고하는거랑 무슨차이인데? ssl인증서는 뭐야? 이렇게 꼬리에 꼬리름 물어가며 생각하게되었던거같다. 그리고 찾아가면서 참 재미있는 주제로 공부했다고 생각도든다. 추후에 내가 머리로 해당 원리를 머리에 그려갈때쯤, 제일 정확하게 확고하고 쉽게 설명한 글을 발견하였다. https://nuritech.tistory.com/25#google_vignette HTTPS 통신 원리 쉽게 이해하기 (F..

어느순간부터 AWS에서 비용이 청구되었다.현재 프리티어 계정인데 1월 부터 비용이 청구되는것을 보고 뭐지싶었다. AWS에서 각각의 서비스들의 한가지씩은 모두 사용하더래도 무료이기때문에 돈이 나갈일이없어야하는데 1월26일자 기준으로 1월은 2.37달러, 2월은 예상 7달러가 나오길래 혹시모르는 내 설정이나 과도한 트래픽이 문제인가 생각하게되었다. 웹소켓을 통해 실시간 주식정보를 받는것도있고 EC2안에서 프로젝트를 시작할때 약 2700개의 주식정보들을 인메모리에 저장하여 쓰기위해서 DB에서 가져오는데 테스트할때는 프로젝트를 껏다가 배포하고 껏다가 배포하고 하니깐 많은 쿼리가 발생한다고 생각했다. 먼저 떠올린건 로드밸런서 도입이후기때문에 로드밸런서가 공짜가 아닌가? 생각을했고 원래부터 프로젝트로는 비용을 내지..

인트로이 주제는 요근래 백엔드 파트로 도메인을 사고 배포하는 과정에서 예전에 제대로 잡히지 않은 부분들이 세팅을 하면서 알게 되어 개인적으로 정리하기 위한 글이라, 해당 개념에 대한 정의나 정해져있는 정보에 대한 글을 쓰지않고 내가 이해한 흐름대로 써내려가고자한다. 상황먼저 상황은 자바스프링부트 프로젝트를 ec2 인스턴스를 생성해서 해당부분에서 build하고 백그라운드로 실행하도록 구현한 상태,postman 및 클라이언트에서 해당 api의 endpoint 별로 데이터가 잘 내려오는지 확인하기위해 public ip address 또는 public dns주소가 필요했고 ec2 인스턴스를 생성시 해당 정보를 제공하기때문에 해당 주소들로 api 테스트하였다. 하지만 http 라는 부분과 ssl 도입이 필요했고 ..

시작처음시작은 하나의 의문에서 시작되었다. 왜 JSON 형태의 객체를 주고받을때 문자열 상태 '{ "a" : "hi" }' 와 같은 형태로 변경되어서 보내거나 받는걸까? JSON이면 우리가 content-type에 지정했듯이 application/json 이라고 명시되어있는데 왜 저렇게 문자열로 주고받아야하고 저걸 불필요하게 직렬화 하거나 역직렬화/파싱 처리를 해야할까? 라는 의문이들었다. 데이터 통신의 형태리서치한 결과 http를 통해 데이터를 보낼수있는 형태는 바이너리 와 문자열(텍스트)로만 가능하다는것이다. 물론 다른 프로토콜을 사용하거나 타입이나 그런건 설정으로 바꿀수있다곤하지만 결국에는 바이너리 or 문자열 이다. 여기서 혼동되면 안되는부분이 header에 들어가는 content-type의 경우..

Singleton Pattern을 사용하여 중복하여 new 인스턴스를 생성하지않고 단일 인스턴스를 활용하여, 서비스 이용시 새로운 인스턴스를 생성하는 비용보다 인스턴스 하나를 공유하도록 설계해야 효율적이고 낭비없는 서비스를 제공하게된다. 하지만 싱글톤 패턴을 적용하려다보면 DIP, OCP를 위반하게되고 별도의 세팅을 위한 public 사용못하도록 Private 생성자함수 생성, new 인스턴스 생성 등을 하는 번거로운 코드작업이 추가되는 등 안티패턴이 생겨 이점보단 단점이 생길수있다고 한다. 하지만 스프링의 경우 이러한 싱글톤패턴의 단점을 제거하고 좋은점을 이끌어내도록 하는데 스프링컨테이너, 스프링의 빈이 이것에 속한다. 먼저 3가지의 경우의 코드를 예시로 보여주겠다. 첫번째는 싱글톤적용없이 사용할때, ..