Dev_Henry

진행중인 프로젝트에서 처음 구현할때 refreshToken도 만들긴 했는데 급하게 만들다 보니 redis 같은 db를 사용한 검증방식도 없었고 어차피 jwt관련 코드가 모두 리팩토링이 필요했기 때문에 refreshToken 부분도 새로 구현하면서 알아보려고 한다. 우선 refreshToken(이하 rtk)은 JWT방식의 단점을 어느정도 보완하고자 생긴 방법인데, accessToken(이하 atk)을 탈취당하면 해커가 계정을 자유롭게 사용할 수 있기 떄문에 atk의 만료시간을 짧게 주고 비교적 만료시간이 긴 rtk을 함께 생성해 둔 뒤에 atk가 만료되었을때 rtk를 통해 atk를 재발급 해주는 방식으로 동작한다.. 라는 내용으로 만들어진 rtk이고 공부를 하면서 찾아본 책, 블로그 등에서도 모두 이정도로..

refreshToken 리팩토링 : https://devsungwon.tistory.com/entry/Spring-JWT-refreshToken%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B3%A0%EB%AF%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0Redis 소셜로그인 리팩토링 : https://devsungwon.tistory.com/entry/Oauth2-%EC%B9%B4%EC%B9%B4%EC%98%A4-%EC%86%8C%EC%85%9C%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%A6%AC%ED%8C%A9%ED%86%A0%EB%A7%81 처음 책을 보고 따라만들어서 jwt토큰 관련 구현이 이상함 문제1. 사용중인 jjwt라이브러리가 옛날 버전이..

채팅목록 관리는 기존 사용하던 방식 그대로 Spring Data JPA와 mysql을 사용했다. 채팅내용을 관리하는 부분에서 어떤식으로 구현을 할지 고민을 많이했다. 처음에는 서버에 저장하지않고 클라이언트에만 저장하려 했으나, 어플이 꺼져있는 동안(소켓연결이 끊겨있는 동안) 온 메시지를 접속시 보여주려면 메시지큐를 다루어야 할것같은데 이 부분이 어렵기도하고 안정성이나 관리 측면을 생각해서 서버에 저장하려고 한다. 하지만 채팅 특성상 채팅데이터가 여러가지 형태로 올 수 있고, 삽입과 조회가 빈번하게 일어나기 때문에 RDB를 사용하면 성능이 떨어질듯 해서 사용해본적 없는 nosql을 써보기로 결정했다. 의존성 추가 implementation ('org.springframework.boot:spring-boo..

현재 프로젝트에서 구현하고자 하는 요구사항은 카카오톡처럼 클라이언트가 꺼져있을때 온 메시지도 받아야하고 내용을 유지시켜야하기 때문에 DB를 연결해야한다. 채팅내용은 어떤식으로 다룰지 고민이 필요하기 때문에 우선 채팅목록과 참여자 등을 관리할 수 있도록 먼저 구현한다. chatRoomDTO @Getter @Setter @NoArgsConstructor public class ChatRoomDTO { private String roomId; // 채팅방 아이디 private String roomName; // 채팅방 이름 private long userCount; // 채팅방 인원수 private List userList = new ArrayList(); public ChatRoomDTO(ChatRoom c..

기본적으로 스프링에서 내장브로커를 제공하지만, 1. 인메모리 형식으로 데이터의 유실 위험도 있고 2. spring boot서버 내에서 함께 처리하기 때문에 서버의 부담도 커진다. 3. 메시지 큐를 모니터링하기 어렵고 4. 또한 현재 프로젝트 규모에서는 아직 필요없지만, 추후 서버를 여러개 둔다면 메시지를 함께 처리할 수 없어 확장성이 떨어진다. 이러한 여러 이유들로 외부 메시지 브로커인 RabbitMQ를 도입하고자 한다. RabbitMQ 의 메시지 전달 과정 1. 송신자가 메시지를 보내면 브로커가 처리과정을 위임받는다. 2. 일종의 우체통 역할을 하는 Exchange로 먼저 전달해서 메시지를 분류한다. 3. exchange에서는 몇가지 종류가 있지만 여기서는 넘어간다. ( Topic은 라우팅 키를 패턴으..

이전 글에서 사용한 방식은 세션을 직접 관리,처리 해주어야했다. 하지만 스프링에서는 웹소켓에 STOMP를 함께 사용할 수 있는 방법을 지원해주는데, 이를 사용하면 메시지처리를 직접하지 않고 편리하게 통신을 구현할 수 있다. STOMP란 Simple Text Oriented Messaging Protocol의 약자로 쉽게 메시지를 주고 받을 수 있게 하기 위한 프로토콜이다. pub/sub 기반으로 작동하며 웹소켓만을 위한 것은 아니나 웹소켓 위에 얹어 편리하게 메시지전송을 구현할수있다. pub/sub 을 간단하게 예로들면 클라이언트들은 특정 주소(채팅방)를 구독할 수 있고, 메시지를 보낸다면 메시지브로커가 해당 주소를 구독하는 모든 클라이언트들에게 메시지를 보여주는 방식이다. stomp를 사용해 통신을 구..

스프링에서 지원하는 웹소켓을 사용하기 위해서는 아래 라이브러리를 사용한다. implementation 'org.springframework.boot:spring-boot-starter-websocket' 소켓통신을 이용하여 채팅을 구현하는 방법을 찾아보면 크게 2가지 방식이 있는데 이번 글에서는 WebSocketConfigurer을 구현하여 소켓을 직접 처리하는 방법을 다룬다. 먼저 소켓 사용을 위한 설정파일을 만든다. 해당방법은 직접 소켓처리를 하는방법이기 때문에 핸들러를 등록해야한다. 핸들러를 등록할때 소켓에 접속하기위한 경로 ("/ws")를 함께 설정해주고, 다른곳에서 접속이 가능하도록 .setAllowedOrigins("*")을 붙여 cors문제를 해결한다. @RequiredArgsConstruc..

작업중인 프로젝트에서 JWT인증방식을 사용하여 로그인을 하도록 만들었다. 대략적인 흐름은 아이디,비밀번호로 로그인을 했을때 스프링 시큐리티에서 login필터를 거쳐서 로그인을 확인하고 성공시 jwt토큰을 발급해준다. 이후 jwt토큰과 함께 요청이 들어오면 토큰체크필터에서 jwt토큰을 검증하는 방식이다. 그런데 책과 자료를 참고하면서 구현하던중 로그인 필터는 AbstractAuthenticationProcessingFilter를 상속받아 구현했지만 토큰체크필터는 OncePerRequestFilter를 이용하는 경우가 많아 필자도 같은 방식으로 구현을 했다. 우선 OncePerRequestFilter에 대해서 찾아보니 모든 서블릿 컨테이너에서 요청 발송 당 단일 실행을 보장하는 것을 목표로하는 필터 기본 클..

프로그래밍 언어들을 공부한지도 시간이 꽤 흘렀고 물론 이제까지 네이밍 컨벤션을 지켜서 코딩하는 것이 좋다는 것을 알고있었다. 자바에서는 가장 기본적인 규칙중 카멜케이스 사용과 변수명은 소문자, 클래스명은 대문자로 시작하는 것 또한 잘 알고있었고 이제까지 그렇게 코딩을 했었지만 나는 이게 개발에 어떤 문제를 일으킬만큼 중요한 것이라고는 생각하지 못했고 단순히 '개발 중 내가, 혹은 협업하는 동료가 헷갈리지 않도록 통일성을 지키는 것' 정로도 생각하고 있었다. ​ 이제까지 학부생활 중 팀프로젝트로 협업한 규모들이 대부분 작았고, 같은 학생들 입장에서 고작 변수명으로 이래라 저래라 하는 것을 팀원들이 나쁘게 생각할수도 있겠다싶어 종종 지키지 않는 팀원들이 있어도 강요는 하지 않았었다. 모순적이게도 '협업을 위..

자바 개발을 할때 많은 사람들이 사용하는 편리한 라이브러리 중 lombok이 있다. lombok은 @Setter, @Getter, @ToString 등의 어노테이션을 제공해주는데, 여러가지를 묶어서 한번에 제공하는 @Data 도 있다. ​ @Data 는 @ToString : 객체를 문자열로 표현할 수 있는 메서드 자동 생성 @EqualsAndHashCode : equals(), hashCode() 메서드 자동 생성 @Getter : getter 메서드 자동 생성 @Setter : setter 메서드 자동 생성 @RequiredArgsConstructor : 필요한 파라리터(초기화 되지 않은 final필드, notnull 필드 등)가 포함된 생성자 자동 생성 ​ 위의 5가지 어노테이션을 한번에 모두 포함시..