0. tistory-card-stat 을 만들려고 한 이유티스토리를 기술 블로그로 활용하고 있는데, 내가 티스토리에 쓴 최신 글 내용을 깃허브 프로필에 가져오고 싶었다. 옆동네 Velog의 경우, 이러한 갈증을 해소해줄 너무나 세련된 카드가 이미 존재한다.만드신 분 깃허브 - enugyeole-velog-readme-stat이렇게 자기 velgo 계정을 넣으면 내용이 보이도록 해주고 있다. 티스토리도 관련된 오픈 소스가 있는지 확인하기 위해 깃허브를 다 뒤졌지만 존재하지 않았다. 아 존재했지만, 더 이상 서비스를 하지 않고 있는 중이었다. 그릿 속의 해빗이라는 개발자 분 께서 Gihub Profile 전용 card-stat을 만들었으나, 더 이상 서비스 하고 있지 않았다.왜 그런지 봤더니, 이유가 다음..

0. 들어가며...현재 구인 구직 서비스의 서버를 만들며, 다음과 같이 구현한 상태이다. 일 (job)과 회원 (member)는 매칭(matching)이란 교차 테이블을 두고, 서로 관계를 맺고 있기에, 연관이 있는 회원은 일과 하나의 상태를 가진다.위의 의뢰인은 일의 주인이다. 따라서 상태는 OWNER만 가진다. 반면 해결사는 자신의 현재 단계에 따라 다른 상태를 가진다. 신청만 했거나 의뢰인에게 선 의뢰를 받은 상태라면, ATTENDER나 REQUEST를 가지고, 의뢰인에게 해결 요청을 승낙 혹은 거절 받거나 혹은 해결사가 선의뢰를 승낙 혹은 거절한 상태이면, YES 혹은 NO라는 상태를 가진다.START는 일을 진짜 시작해야만 가지는 상태이며, SLEEP은 해결사가 일 해결에서 노쇼한 경우 의뢰인이..

0. 들어가며...현재 진행하고 있는 구름 PROTECT에서 구현한 API에 대한 성능테스트를 하고 있다. 필자는 진정한 대량의 성능 테스트를 위해서는 매번 다른 JWT 토큰 값이 Header에 담겨야 한다고 생각했다. 이유는 다음과 같다.실제와 같은 환경을 최대한 구현할 수 있다. 실제 서비스에서도, 다른 사용자는 한 명도 사용하지 않는데, 한 사람만 요청을 5만 번 하는 경우는 극히 드물 것이다. 한 사람이 매번 같은 요청을 할 경우, DB 캐싱과 서버 캐싱으로 해당 내용이 메모리에 저장될 것이므로, 진정한 서버의 성능을 볼 수 없을 것이라 판단했다.따라서 여러 명이 서비스를 각자 사용하고 있는 것을 흉내내고자 HEADER의 Authorization에 매 번 다른 토큰 값을 넣었다.1. 토큰 생성 ..

0. 로그가 흰색이면...보기가 힘들다.이게 인텔리제이에서 보면 그나마 나은데, 배포된 서버로 들어가 로그를 볼려고 치면 정말 구분히 힘들어진다. 이를 위해로그 레벨 별로 색깔을 적용하여 가독성을 높이려 한다.1. 적용 방법(1) 파일 구조 및 의존성 삽입resources 부분에 logBack을 둔다. 이후 로깅과 실제 구현 코드 간의 관심사 분리를 위해 @SLF4J 라이브러리를 삽입한다. 이 라이브러리를 쓰지 않으면 로그를 쓰고 싶은 모든 클래스마다 Logger 객체를 주입 받아야 한다. 이는 객체간의 결합도를 높이고, Logger 기능 자체의 유연성도 줄인다. (처음엔 Log-Back 라이브러리를 쓰다가 Log4j로 바꾸고 싶을 때 @SL4FJ를 안 쓴다면 모든 Logger 멤버를 바꿔줘야 한다;;)..

0. 왜 필요한가외부 API나 DB, 미들웨어 연동을 위해서는 활용을 위해 약속한 secret-key를 들고 있어야 한다. 보통 개발자들은 설정파일에 그것을 몰아넣고, @Value()를 활용하여 그것들을 불러온다. 다음 사진과 같이 말이다.이런 secret-key들은 유출되면 해킹 등 프로젝트에 치명적인 위협을 준다. 그래서 개발자들은 항상 이것들에 대해 신경 쓰고, 인프라 팀 또한 Jenkins나 DockerHub에 키 리스트들을 따로 관리해야 해서 골치 아프다. 이를 해결하기 위해 Java의 라이브러리인 Jasypt를 활용했다.1. Jasypt란?(0) 정의단방향 암호화 혹은 단일 키 양방향 암호화를 가능하게 해주는 라이브러리이다. 이 라이브러리의 강점이라 한다면 Jasypt로 암호화한 대상을 특정하..

0. 필요성저번에 했던 6인 프로젝트의 반환 환경 모습이다. 당시 ResultResponse라는 팀 내의 공통 응답 규칙을 정하고, ResponseEntity로 반환하기 전에 DTO를 ResultResponse로 한 번 더 감싸서 반환했다.그 당시에는 큰 불편함 없이 했던 것 같지만, 다시 보니 2가지 불편 사항이 있었다.1️⃣ 매서드의 반환 타입을 항상 ResponseEntity와 ResultResponse로 감싸줘야 한다. 실제 필자가 프론트 개발자에게 줘야할 JSON 반환 객체는 TokenDTO인데, 그저 반환 규칙을 위해서 프로세스에서는 불필요한 객체를 추가해야만 한다.2️⃣ 같은 이유로 반환값 또한 두 객체를 활용해 감싸줘야 한다.이는 3인의 백엔드 개발자 중 한 명이라도 실수로 ResultRe..

1. Token 인증 방식이 어떻게 이루어 지는가회원이 로그인을 시도한다고 가정해보자.ⓐ Client가 ID/PW 로그인 창에 써서 제출한다.ⓑ Server가 DB를 통해 해당 ID/PW를 가진 회원이 있는지 확인한다.여기서 해당 회원의 정보가 우리 DB에 있어서 우리 회원인 것이 확인 되었다고 가정해보자.ⓒ Server에서 해당 회원의 정보를 이용하여 고유한 Token을 만든다.ⓓ 그리고 해당 토큰을 아까 유효한 요청을 한 클라이언트에게 보내준다.ⓔ 이제 클라이언트는 인증이 필요한 API를 이용할 경우 해당 Token을 요청 Header에 동봉하여 같이 보낸다.ⓕ 이제 서버에서는 해당 Token의 유효성을 검증 후 유효한 토큰이 맞다면 응답으로 요청한 내용에 대한 정상 답변을 보내주면 된다.그렇다면 기..

1. Git Shelve - 잠시 다른데 다녀올거니까. 작업하던 거 선반에 올려두자!git shelve를 하면 해당 Branch의 임시 저장소에 저장된다.현 branch의 변경사항을 들고, 다른 branch에 놔두는 행위를 못한다.해당 브랜치에 작업 하던 것을 임시 저장하고, 다른 branch에서 일 본 뒤에 다시 돌아와서 unshelved 하면 된다.임시저장한 거 빼내 오려면저걸 눌러서 다시 changes로 들고와야 한다.unshelved 했다고 해서 shelf에 저장된 임시 저장 내역이 사라지지 않는다. 없애고 싶다면 삭제하자.2. git stash / unstash - 현 branch에서 작업한 내역 들고 다른 branch로 갈래. 거기서 작업 계속 이어 갈래Intellij 에서는 git -> un..

1. 개요4월 5일부로 특화 프로젝트가 끝났다. 이번 프로젝트에서 보안을 맡았는데, 항상 내가 맡은 파트를 정리해야겠다는 생각을 했다. 벌써 2주 반이 흘렀기에, 더 까먹기 전에 미리 정리해두려한다.해당 프로젝트의 전문을 보고 싶다면, 다음을 확인하자.SSAFY 10기 구미 2반 특화프로젝트 WALK_WALK2. 전개도3. 코드 분석(1) JwtAuthFilter 안에 있는 JwtUtil 분석import io.jsonwebtoken.*;import io.jsonwebtoken.security.Keys;import jakarta.annotation.PostConstruct;import jakarta.servlet.http.HttpServletRequest;import lombok.RequiredArgsCo..

1. JWT란 무엇인가?기본적인 토큰 인증 방식을 따르고, 거기서 토큰 자체를 강화한 방식이라 생각하면 된다.원래의 토큰 인증 기반에서 요청자가 보내온 ID/PW 가 DB에 존재하면 (우리 회원이 맞으면) 그 요청자에게 자신들의 API를 쓸 수 있는 허가증인 토큰을 전해줬었다. 여기서 더해 JWT의 경우 토큰을 만들 때, 사용자의 정보(간단한 개인정보 등 +@)를 암호화하여 만든다.이렇게 되면 무엇이 좋을까?아까 토큰 자체가 사용자에 대한 개인 정보라고 하였다. 회원가입을 하여 토큰을 받았다면, 이후 API 요청을 할 때, 토큰을 Header나 Cookie에 넣어서 보낸다. 만약 클라이언트가 원하는 요청이 사용자의 개인정보에 대한 요청이라면, 서버에서는 DB를 조회할 필요없이 토큰을 복호화 하여 그 안의..

원본 문서AOP가 담고있는 발상AOP가 가지고 있는 몇몇 중심적인 생각들과 용어들을 정의하는 것으로 시작해보자! 여기서 쓰이는 용어들은 스프링 맞춤이 아니다. 따라서 불행하게도 AOP의 용어들은 특별히 직관적이진 못하다. 하지만, 만약 스프링이 AOP 개념 도입을 위한 그것만의 용어를 썼다면, 그것이 더 우리를 혼란스럽게 만들 것이다!1. 용어설명Aspect(관점): 복수의 Class들을 가로지르는 관심사에 대한 모듈화를 의미한다.(기존의 우리가 서버 로직을 공부할 때, 기능을 무엇이라 생각했는가? Service Class 하나가 곧 기능이라고 생각했다. 하지만 AOP에서는 관점을 달리하여, 클라이언트로부터 요구가 들어와서 Controller -> 복수의 서비스 로직 -> 다시 응답 까지의 전 과정을 하..

깃허브에도 정리 올려놓았습니다.전수민_깃허브 주소Weaving과 Proxy 객체에 대하여이번 장에서 알아볼 것:AOP에서 Weaving이란 무엇인가? Proxy와의 관계는 어떻게 되는가?Proxy 객체란 무엇이고? AOP에서 사용되는 원리는 무엇인가?1. AOP에서 Weaving이란 무엇인가?AOP에서 weaving이란 부가기능(advice)을 그것이 타겟팅하는 본 기능에 장착하는 작업을 말한다. 따라서 weaving은 본기능에 영향을 주지 않으면서 부가기능을 연결시키는 AOP의 핵심 작업이다.weaving은 실행되는 시점에 따라 3가지로 종류가 나뉜다.(1) Compile Time Weaving(CTW)Spring에서 AOP를 구현하는 방법에는 AspectJ라는 라이브러리를 쓰는 것과, Spring A..

Spring AOP 공식 문서 읽고 스스로 정리함.깃허브에도 올려놓음https://github.com/dalcheonroadhead/Spring-framework-theory/blob/main/AOP/relatedStudy/conceptOfAOP.mdConcept-of-AOP 스스로 정리목차AOP란 무엇인가?그림과 함께 알아보는 용어 정리AdviceJoin PointpointcutAspectIntroductionTarget ObjectAOP proxyWeavingCross-cutting concerns1. AOP란 무엇인가?Aop는 관점 지향 프로그래밍(Aspect Oriented Programming)을 말한다. Java라는 언어를 배울 때 우리는 자바가 객체지향프로그래밍(Object Oriented ..

목차1. OAuth2의 등장 배경 (OAuth2란 왜 필요한가?)2. 그래서 OAuth2란?3. OAuth2 관련 용어 정리 4. OAuth2의 동작 과정 1. OAuth의 등장 배경  (OAuth2란 왜 필요한가?)현 IT 서비스 시장에는 구글이나 아마존, 트위터와 같은 메가급 기업들이 다수 존재한다. 이 기업의 사용자들은 수천만 많게는 억대 단위로 넘어간다. 그 만큼 해당 기업들이 가진 리소스도 다수 존재할 것이다. 하지만, 단체생활을 해봤다면 알 수있듯이 하나의 일을 작업자 전원이 만족하는 방식으로 수행한다는 것은 불가능에 가깝다. A는 서류 작업을 더 완벽히 하고 다음 일로 갔으면 좋겠고, B는 그저 본 작업을 빨리 진행하고 싶을 수도 있다. 이는 우리가 특정 서비스를 이용할 때도 마찬가지이다. ..

0. 목차1. 개요 - 이전과 달라진 점2. 전개도 3. 코드 분석4. 프로젝트 진행하면서 겪었던 오류들https://www.daddyprogrammer.org/post/5290/spring-websocket-chatting-server-enter-qut-event-view-user-count/ 를 보고 진행 했습니다.  1. 개요 ⓐ 입장 퇴장 시 인원 수 체크해서 인원 수를 채팅방에 표시 ⓑ 저번 포스팅까지는 채팅방 입장과 구독을 클라이언트에서 인지하고 백엔드로 보내주고, 그에 대한 처리를 했음. 이번에는 Sever Side에서 해당 이벤트를 직접 인지 하고, 일을 처리하도록 바꿨음.  2. 전개도  원래 배울 때 Controller -> service -> Repository로 일이 정해져 있었지만..

0.목차공부한 내용들의 출처: ddadyProgrammer님의 블로그 Spring websocket chatting server(4) - SpringSecurity + Jwt를 적용하여 보안강화하기이번 장에서는 SpringSecurity와 Jwt를 이용하여 Web 및 Websocket의 보안을 좀 더 강화하고. 기존의 복잡한 로직을 간소화하는 작업을 진행해 보겠습니다. 크게 아래의 3가지 작업을 진행하겠습니다. Spriwww.daddyprogrammer.org1. 개요 (새롭게 추가한 것들)2. 전개도 3. 코드 분석4. 프로젝트 진행하며 만났던 오류 모음 1. 개요 이번 장에서는 새롭게 Spring Security를 적용했다. 원래 프로젝트는 접근한 모든 사용자가 대화명만 입력하면 모두 사용할 수 있었..

https://www.daddyprogrammer.org/post/4731/spring-websocket-chatting-server-redis-pub-sub/0.목차1. 개요 2. 전개도, 전체적인 흐름 파악3. 코드 분석 4. 프로젝트 진행하면서 있었던 에러 해결 1. 개요 이번 프로젝트에서는 Redis라는 인메모리형 DB를 활용하여 2번까지 진행했던 STOMP와 WebSocket만으로 구현한  Chatting Server 프로젝트를 더 고도화 하려고 한다.  어? 이미 하나의 서버에서 서로 메세지를 주고 받는 것은 충분히 되는데 왜 Redis를 장착해야 할까요?그렇다면, 먼저 Redis를 왜 장착해야 하는지에 대해서 설명하겠다.ⓐ STOMP와 WebSocket만을 쓰는 Chatting Server의..

본 프로젝트는 스프링 웹소켓 채팅서버 만들기 를 실습하며 공부하기 위한 프로젝트 입니다. branch 별로 총 6단계 모두 진행할 예정입니다.0. STOMP란 무엇인가?Stomp란 SimpleTextOrientedMessagingProtocol의 약자로, 텍스트 기반 양방향 통신을 효율적으로 하기 위한 통신 규약이다.Stomp의 원리는 다음과 같다. Stomp에는 3가지 개념이 존재하는데, Topic, Publisher, Subscriber가 그것이다.Topic은 우체통이라고 생각하면 된다. publisher는 메세지 발행자이다. Publisher가 어떤 Topic을 EndPoint로 잡고 메세지를 보내면 해당 우체통으로 메세지가 들어간다. 이때 해당 Topic을 구독하고 있는 Subscriber들에게 ..

본 프로젝트는 스프링 웹소켓 채팅서버 만들기 를 실습하며 공부하기 위한 프로젝트 입니다. branch 별로 총 6단계 모두 진행할 예정입니다.해당 내용으로 만든 프로그램입니다. 첫 단계라서 firstStep이란 branch에 저장하였습니다.https://github.com/dalcheonroadhead/WebSocketBEPractice/tree/firstStep1. 전개도1-1 Server Logic해당 블로그의 Basic WebSocket의 전개도 이다.아주 간단하게 처리했기 때문에 아직 DB와 연결하지 않고, 서비스와 컨트롤러, 모델, 웹소켓 설정 디렉토리만 필요했다.1-2 Server와 Client 전체 Logic먼저 내가 헷갈렸던 부분은 Rest API와 소켓이 다른 장소에서 mapping 된다..