이 글은 JWT, 액세스 토큰, 리프레시 토큰 등에 대한 개념적 정리이다. 목차 1. 개선 이전 상황 2. 액세스 토큰, 리프레시 토큰 정리 3. 구현 내용 4. 자체적인 질문과 응답 1. 개선 이전 상황 나는 JWT를 통해 인증&인가 관련 기능을 구현하였었지만, 액세스 토큰과 리프레시 토큰을 구분하지 않고 만료시간이 일주일 정도로 긴 하나의 토큰만 사용중이였다. 이를 개선해 본다. 2. 액세스 토큰, 리프레시 토큰 정리 개선 이전의 내 방식은 어떤 문제가 있을까? 1. 토큰 만료일이 일주일로 매우 길다. 2. 토큰 탈취시 강제 만료시킬 방법이 없다. 사용자가 매번 로그인을 해야하는 불편함을 없애기 위해 만료시간을 길게 하였지만, 토큰을 탈취당하면 긴 시간동안 악의적 행동에 시달려야 하며, 만료일 전까지..
이 글은 정답이 아닌 개인적인 저의 생각 정리입니다...! . . . 고민 개발을 하다보면 계속 Controller와 Service의 역할에 대한 의문이 들었다. Controller가 Service에 있어야할 비즈니스 로직을 가지고 있게 된다고 생각했기때문이다. (내가 그렇게 했기때문에 그런거지만... ㅠㅠ) 실제로 내가 겪은 구체적인 상황: 어떤 컨트롤러의 post 요청에서 A,B,C 엔티티가 반드시 순서대로 생성된후 저장되어야 한다. (참조관계 때문에 그렇다) 기존에는 컨트롤러에서 A 엔티티 생성 -> AService.createA() 한 후 B, C도 동일한 과정을 거침. 이러니까 컨트롤러가 서비스의 역할을 해버린다고 생각함. 코드: //기존 코드 @PostMapping public Response..
테스트 코드를 잘 써야한다. 서비스 장애를 사전에 방지하고, 품질 좋은 코드를 만들게 되며, 시간을 꽤 들여서 테스트 코드를 작성해도 결국 나중에는 그게 시간을 아끼도록 해주기 때문이다. 무엇보다 중요한건 그래야 면접관이 좋아한다. 그걸 나도 아는데, 솔직히 테스트 코드 쓰는 시간을 좋아한다고는 못말하겠다... 그래도 개판인 내 테스트코드를 개선하는 시간을 가져본다... 솔직한 내 현재 상황: 1. 테스트 클래스 통째로 주석처리함 요구사항 빨리 개발해서 쳐내다가 너무 많이 기능이 추가되고 기획이 수정되서 일부 테스트 통과 안되서 걍 편하게 ctrl + A -> ctrl + ? 눌러버림 마지막 양심으로 postman 보면서 수작업 테스팅함 2. 근거없이 오직 @SpringBootTest 통한 통합 테스트만..
beanstalk을 쓰면 업데이트 할때마다 구성요소를 갈아 치운다. 그래서 따로 돌아가는 RDS를 beanstalk으로 생성한 ec2와 직접 연결해줘야한다. 민감한 정보(db/aws configuration)를 깃헙에 그냥 올리면 안되니까, beanstalk 쓰기 전처럼 그냥 ssh 접속해서 인스턴스에 application.yml을 프로파일 구분해서 만들면 되지 않을까? 하고 생각없이 작업하고있었는데, 이 글 맨위에 적어놓은게 생각났다 아 근데 이거 어차피 다 날리는데...? 다른 방법을 찾아봐야했다. 좀 보다보니까 구글에 찾아봐도 잘 나오고, 공식문서에도 나와있다 https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/java-rds.html Ama..
2주전 정도인가에 학교 에브리타임에서 프로젝트 팀 구인글을 봤다. 망해도 포트폴리오 라는 이름을 ㅋㅋㅋㅋㅋㅋㅋㅋ 가진 팀에서 북클럽 서비스를 기획하고 있는데 디자이너, 기획자, 안드로이드 앱 개발자가 모인 팀에서 서버를 개발해줄 백엔드 개발자가 필요하다는 글이였다. 이런식으로 글이 올라왔는데 딱봐도 뭔가 준비된듯하고 열심히 할 것같은 팀이였다. 마침 나도 프로젝트에 관심이 있었던 참이였는데 좋은 기회라고 생각했다. 그래서 문의를 보내고 팀에 합류했다. 나말고도 Swift 개발자 한분이 더 합류했다. 현재는 회의를 2번 마친 상태이다. 처음에는 그냥 통성명과 간단한 이야기 정도만 했다. 두번째에는 설문조사, 필수기능 정리, 기획 수정 등의 일을 했다. 회의를 좀 깊은 밤에 길게 하긴 했지만 그래도 재미있었..
Servlet- 서블릿은 예전에 스프링같은 편리한 프레임워크를 사용하기전 사용했다고한다. 서블릿의 역할 서블릿은 프로그래머가 핵심적인 코드만 작성하도록 도와준다. 의미있는 비즈니스 로직 외에도 저런 수많은 작업을 처리해줘야 한다. 연결하고 파싱하고 연결끊고... 이런걸 전부 한땀한땀 하기에는 너무나도 힘들다. 난 대학에서 네트워크 시간에 http connection을 만들고 파싱하고 이런걸 해봐서 이 고통을 이해한다. 그게 싫었던 사람들은 서블릿을 만들어냈다. 스프링부트는 기본 내장 was로 톰켓을 사용한다. was로 http 요청이 들어오면 was는 response와 request 를 생성하여 서블릿컨테이너에서 싱글톤으로 관리되는 서블릿 객체에 넘겨준다. + 동시요청에 대비해 멀티쓰레딩을 이용해 서블릿..
출처: 자바 ORM 표준 JPA 프로그래밍 주된 이유: 패러다임의 불일치 . . . ===객체지향 언어와 관계형 데이터베이스의 차이에서 오는 어려움=== -객체를 테이블에 맞추어 모델링 해야함: 객체는 상속관계, 테이블은 슈퍼타입 서브타입 관계, 객체는 참조 사용, 테이블은 외래키 사용 -진정한 의미의 계층분할이 어려움: DAO 작성자와 service 작성자가 다를때, 서비스에서 DAO를 맘놓고 못쓴다. 쿼리가 실제로 어떻게 나가는지 일단 확인해야하기 때문이다. -객체를 자바 컬렉션처럼 디비에 저장하고 사용하고싶음: 그래야 다형성, 객체 그래프 탐색 등이 쉬움 종합하면, 프로그래머는 객체지향 프로그래밍의 장점을 살려서 프로그래밍 하고싶다. 그러나 패러다임의 불일치로 인해서 급한 불을 끄는 식으로 sql ..
김영한님의 JPA 인강을 드디어 다 들었다. 17시간 짜리 강의이고, 강의 내용도 쉽지않아서 힘들었다. 사실 난이도 자체가 너무 어렵고 이해가 죽어도 안된다는 느낌은 아니였고, 강의에서 안다고 전제하고 설명하는 것들, 초반부에 알려주고 제대로 복습이 안된것들에 대해서 슉슉 지나가는 느낌이여서 힘들었다. DB설계와 SQL에 관한 내용들이 특히 알쏭달쏭했다. 하지만 이 강의를 듣기 잘했다고 생각하는게, 이렇게 내가 뭘 모르는지 아는 상태가 되는것이 너무너무 필요했기 때문이다. 이제부터 강의를 쭉 복습해서 블로그에 정리하고, 남은 강의들을 빨리 듣고나서 토이 프로젝트를 얼른 해보고싶다.
