https://www.cloudflare.com/ko-kr/learning/ssl/why-is-http-not-secure/

 

HTTP와 HTTPS 차이점

  • HTTPS 는 암호화 및 인증이 포함된 HTTP 이다 . 
  • 두 프로토콜의 유일한 차이점은 HTTPS가 TLS ( SSL )를 사용하여 일반 HTTP 요청 및 응답을 암호화하고 해당 요청 및 응답에 디지털 서명한다는 것.
  • 결과적으로 HTTPS는 HTTP보다 훨씬 더 안전하다.
  • HTTP를 사용하는 웹사이트는 URL에 http://가 있고 HTTPS를 사용하는 웹사이트는 https://가 있다.

 

HTTP란?

  • HTTP는 Hypertext Transfer Protocol의 약자이며 네트워크를 통해 데이터를 전송하는 데 사용되는 프로토콜이다. 
  • 웹 사이트 콘텐츠 및 API 호출을 포함하여 인터넷을 통해 전송되는 대부분의 정보는 HTTP 프로토콜을 사용한다. 
  • HTTP 메시지에는 요청과 응답이라는 두 가지 주요 종류가 있다.

 

HTTP 요청/응답

  • HTTP 요청은 사용자가 웹 속성과 상호 작용할 때 사용자의 브라우저에서 생성된다. 
  • 예를 들어 사용자가 하이퍼링크를 클릭하면 브라우저는 해당 페이지에 나타나는 콘텐츠에 대한 일련의 "HTTP GET" 요청을 보낸다. 
  • 누군가 Google에서 "HTTP가 무엇인가요?"라고 검색하면 어떤한 페이지는 검색 결과에 표시되며 링크를 클릭하면 브라우저가 페이지를 렌더링하는 데 필요한 정보를 얻기 위해 일련의 HTTP 요청을 생성하고 보낸다.
  • 이러한 HTTP 요청은 모두 origin server 또는 proxy caching server로 이동하며 해당 서버는 HTTP 응답을 생성한다. 
  • HTTP 응답은 HTTP 요청에 대한 응답을 의미한다.

 

HTTP 요청의 모습

HTTP 요청은 HTTP 프로토콜을 따르는 일련의 텍스트 줄이다. GET 요청은 다음과 같다.

  • 사용자의 브라우저에서 생성된 이 텍스트 섹션은 인터넷을 통해 전송된다. 
  • 문제는 연결을 모니터링하는 모든 사람이 읽을 수 있는 일반 텍스트로 위와 같이 전송된다는 것
  • 이는 사용자가 웹사이트나 웹 애플리케이션을 통해 민감한 데이터를 제출할 때 특히 문제가 된다.
  • 오고가는 데이터는 암호, 신용 카드 번호 또는 양식에 입력된 기타 데이터일 수도 있고 HTTP에서는 이 모든 데이터가 누구나 읽을 수 있도록 일반 텍스트로 전송된다. 

  • 웹 사이트에서 HTTPS 대신 HTTP를 사용하는 경우 세션을 모니터링하는 모든 사람이 모든 요청과 응답을 읽을 수 있다. 
  • 즉, 헤커는 요청 또는 응답의 텍스트를 읽고 누군가가 요청하거나 보내거나 받는 정보를 정확히 알 수 있다.

 

HTTPS란?

  • HTTPS의 S는 "보안(Secure)"을 의미한다. 
  • HTTPS는 TLS(또는 SSL)를 사용하여 HTTP 요청 및 응답을 암호화하므로 공격자는 텍스트 대신 겉보기에 무작위로 보이는 암호화된 여러 문자를 보게 된다.

 

헤커는 아래와 같은 데이터 대신에

 

다음과 같은 것을 보게 된다.

t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==

 

HTTPS에서 TLS/SSL은 HTTP 요청 및 응답을 어떻게 암호화하는가?

  • TLS는 공개키 암호화 라는 기술을 사용한다 .
  • 공개키(public key)와 개인키(private key)의 두 가지 키가 있으며 공개키는 서버의 SSL 인증서를 통해 클라이언트 장치와 공유된다. 
  • 클라이언트가 서버와의 연결을 열면 두 장치는 공개키 및 개인키를 사용하여 세션키(session keys) 라고 하는 새로운 키에 동의하여 둘 사이의 추가 통신을 암호화한다.
  • 그런 다음 모든 HTTP 요청과 응답은 이 세션키로 암호화되므로 통신을 가로채는 사람은 일반 텍스트가 아닌 임의의 문자열만 볼 수 있다.

 

HTTPS는 웹 서버를 인증하는 데 어떻게 쓰이는가?

  • HTTP에서는 신원 확인이 없으며 신뢰 원칙을 기반으로 한다. 그러나 현대 인터넷에서는 인증이 필수적입니다.
  • ID 카드가 개인의 신원을 확인하듯이 개인키는 서버 신원을 확인한다. 
  • 클라이언트가 origin server와 채널을 열 때(예: 사용자가 웹 사이트를 탐색할 때) 웹 사이트 SSL 인증서의 공개키와 일치하는 개인키를 소유하면 서버가 실제로 웹 사이트의 합법적인 호스트임을 증명한다. 
  • 이렇게 하면 다음과 같이 인증이 없을 때 발생할 수 있는 여러 공격을 방지하거나 차단하는 데 도움이 된다.
    • On-path attacks
    • DNS hijacking
    • BGP hijacking
    • Domain spoofing

또한 SSL 인증서는 인증서를 발급한 인증 기관에서 디지털 서명된다. 이를 통해 서버가 자신이 주장하는 사람인지 확인할 수 있다.

 

 


[ 참고 자료]

https://www.cloudflare.com/ko-kr/learning/ssl/why-is-http-not-secure/

 

[ AWS로 https 설정하는 법 참고자료 ]

 

https://velog.io/@server30sopt/EC2-HTTPS%EB%A1%9C-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0

 

EC2 HTTPS로 연결하기

👾 작성자: 이승헌🐬 작성자의 한마디: https로 연결은 눈감고 한다우선 해당 글을 포스팅하기에 앞서 http에서 굳이 https로 연결하는 이유에 대해 이야기해보려 합니다.HTTP는 Hyper Transfer Protocol의

velog.io

https://pgmjun.tistory.com/69

 

[AWS] EC2 도메인 연결 및 HTTPS 적용하기

EC2 도메인 연결 & EC2 HTTPS 적용 안녕하세요 오늘은 AWS EC2에 도메인을 연결하고 HTTPS까지 적용해보는 시간을 갖도록 하겠습니다. 이 글은 이전에 생성한EC2가 이미 있다는 가정하에 HTTPS와 도메인

pgmjun.tistory.com

 

Access Token의 문제점

사용자의 잦은 로그아웃 경험

현재 진행중인 나몰닭 프로젝트는 Access Token 만을 사용하여 사용자를 인증한다. Access Token 유효 기한인 1시간이 지나면 유저는 로그아웃되고 다시 로그인을 진행해야 한다. 게임을 하다 중간에 방을 나왔을 때 로그인을 다시해야 한다면 굉장히 불편한 서비스 경험이 될 것이다. 그렇다고 유효 기간을 길게 한다면 아래와 같은 보안상의 문제가 발생한다.

 

보안 문제

Access Token은 JWT이므로 그 자체로 인증 정보를 모두 가지고 있어서 탈취되면 위험한 상황이 발생할 수 있다.  토큰 기반 인증 방식에서 토큰은 세션과 다르게 stateless 하다. 서버가 상태를 보관하고 있지 않다는 이야기이다. 서버는 한번 발급한 토큰에 대해서 제어권을 가지고 있지 않다. 즉, 토큰이 탈취될 경우 서버에서 토큰이 만료될때까지 기다리는 것 말고는 막을 방법 없이 사용자 계정의 제어권을 해커에게 내어줄 수 밖에 없다는 것이다. 

 

Refresh Token 이란?

목적

Refresh Token의 목적은 Access Token의 유효 기간을 짧고, 자주 재발급 하도록 만들어 보안을 강화하면서도 사용자에게 잦은 로그아웃 경험을 주지 않도록 하는 것이다.

Access Token은 리소스에 접근하기 위해서 사용되는 토큰이라면, Refresh Token은 기존에 클라이언트가 가지고 있던 Access Token이 만료되었을 때 Access Token을 새로 발급받기 위해 사용한다.

Refresh Token은 서버에 저장되기 때문에(stateful) refresh token이 해커에 의해 탈취당했다고 판단되었을 때 서버에서 refresh token을 삭제함으로써 강제 로그아웃을 시킬 수 있다. 이런 특징을 이용해서 access token + refresh token의 조합을 구성하면 access token의 경제적인 장점 refresh token의 보안적인 장점을 둘 다 챙길 수 있다.

 

유효 기간

Refresh Token은 Access Token 대비 긴 유효 기간을 갖는다. Refresh Token을 사용하는 상황에서는 일반적으로 보안적으로 취약한  Access Token의 유효기간은 30분 이내, Refresh Token의 유효기간은 처리 비용이 많이 들기 때문에 2주 정도로 설정한다고 한다. 유효 기간은 서비스 성격에 따라 적절하게 설정 해야한다.

 

Access Token + Refresh Token 인증 과정

https://tansfil.tistory.com/59

 

1. 사용자가 ID , PW를 통해 로그인한다.

2. 서버에서는 회원 DB에서 값을 비교한다. 

3~4. 로그인이 완료되면 Access Token, Refresh Token을 발급한다. 이때 일반적으로 회원DB에 Refresh Token을 저장한다.

5. 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보낸다.

6~7. Access Token을 검증하여 이에 맞는 데이터를 보낸다.

8. 시간이 지나 Access Token이 만료된다.

9. 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보낸다.

10~11. 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보낸다.

 

** Access Token 만료가 될 때마다 계속 과정 9~11을 거칠 필요는 없습니다.

 사용자(프론트엔드)에서 Access Token의 Payload를 통해 유효기간을 알 수 있습니다. 따라서 프론트엔드 단에서 API 요청 전에 토큰이 만료됐다면 바로 재발급 요청을 할 수도 있습니다.

 

12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보낸다.

13. 서버는 받은 Access Token이 조작되지 않았는지 확인한후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해준다.

14. 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청을 진행한다. 

 

Refresh Token의 한계

Access Token을 즉시 차단할 방법의 부재

아무리 Refresh Token이 Access Token의 유효기간을 짧게 만들어 줄 수 있다고 하더라도, 탈취된 Access Token이 유효한 그 짧은 시간 동안에 악용될 수 있다는 위험성이 존재한다.

 

Refresh Token 그 자체를 탈취 당할 가능성

해커에게 Refresh Token 자체를 탈취 당하면 해커는 마음껏 Access Token을 발행할 수 있다. 서버 DB에서 Refresh Token을 저장해 직접 추적하는 방법을 사용하면 조금이나마 피해를 줄일 수 있겠지만, 피해가 확인되기 전까진 탈취 여부를 알 방법이 없다.

RTR을 사용한다면 Refresh Token을 1회 사용하고 버리게 되어 더 안전하게 사용할 수 있지만, 사용하지 않은 Refresh Token을 탈취당하면 해커는 1회 한정으로 Access Token을 발급받을 수 있다.

즉, 이러나 저러나 Refresh Token을 탈취 당할 위험성이 존재한다. 따라서 클라이언트는 XSS, CSRF 공격으로부터 Refresh Token이 탈취되지 않도록 안전하게 보관해야한다.

 

더보기

Refresh Token을 서버에 저장할 시 고려해볼 사항

보안 - 정상적인 사용자의 ip가 아니라면 refresh token을 삭제하도록 하기

refresh token은 서버에 저장된다. 그래서 보안적인 문제가 생기면 refresh token을 삭제함으로써 특정 사용자를 강제 로그아웃시킬 수 있다. 최초 로그인 한 ip를 서버에 저장하고, refresh token을 통한 access token 갱신 요청이 다른 ip로부터 온다면 비정상적인 접근으로 판단하고 refresh token을 삭제하여 강제 로그아웃시킨다.

그런데 이 방식도 UX적으로 단점이 있다. 요즘 항상 같은 곳에서만 컴퓨터를 사용하는 유저가 얼마나 되겠는가. 지금 글을 작성하는 시점에도 많은 사람이 카페에서 노트북을 사용하고 있는데 ip가 달라진다고 해서 강제로 로그아웃시킨다면 사용자 경험에 좋지 않을 것이다.

-->  네이버나 카카오톡처럼 ip가 달라지는 경우 보안 알림을 사용자에게 띄워 준다. 여기서 “아니요” 를 선택한다면 로그아웃되는 구조로 풀 수 있을 것 같다.

 

UX - 사용 중에 access token이 만료된다면 조용히 재발급 받기

만약 어떤 사용자가 새로 고침하지 않고 화면을 2시간 이상 띄워놓는 경우를 가정해보자. 가장 흔한 경우는 글을 작성하는 경우가 있다. 이 경우에는 access token이 만료되었다는 사실을 사용자가 모르게 하는 것이 가장 자연스러운 경험일 것이다.

 

방법 1) 요청 보낼 때 token 만료 에러가 발생하면 token을 새로 발급받기

인가가 필요한 요청을 보낼 때 token 만료 에러가 발생하면 token을 새로 발급받고, 새로 발급받은 token으로 다시 요청을 다시 보내는 것이다.

장점

  • 사용자가 인가가 필요한 작업을 요청할 때만 token이 재발급되어 경제적이다.

단점

  • 인가가 필요한 요청에 대한 에러처리, 재요청 로직이 추가로 요구된다.
  • token이 만료된 경우 인가가 필요한 요청을 결과적으로 2번 보내야한다.
  • token이 만료된다면 첫번째 요청은 실패할 것이고, 새로운 token을 발급받아 두번째 요청을 보내야 한다. 큰 문제가 되지는 않을테지만 단점이라 할 수 있다.

방법 2) 일정 시간마다 새로운 access token을 발급 받기

access token 만료 기간이 2시간이라면 1시간 55분 정도에 새로운 token을 발급한다. 이 방법을 사용하면 요청 관련 로직을 수정하지 않아도 되어 편리하다. 사용자가 사용하지 않을 때에도 백그라운드에서 계속 새로운 token을 발급받는다는 단점이 있을 수 있지만, 이것도 브라우저 포커스가 되어있는지를 감지해서 최적화도 가능하므로 큰 문제가 되지 않을 것으로 생각한다.

장점

  • setTimeout으로 token 재발급 로직만 작성해주면 요청 관련 로직 수정이 필요 없다.

단점

  • 시간과 관련하여 token을 재발급 받기 때문에 특정 시간이 지나면 무조건 재발급 요청을 보내어 비효율적일 수 있다.

 

 


[ 참고 자료]

 

 

refresh token 도입기

❗ SSR 상에서 refresh token을 도입하면서 느낀 것들을 작성한 글입니다. ❗ SSR에서 로그인이 어떻게 이루어지는지 궁금하시면 여기를 참고해주세요! 도입 계기 - 2시간이 지나면 로그인이 풀린다!

tecoble.techcourse.co.kr

 

Spring Boot와 Redis를 사용하여 Refresh Token 구현하기

배경 바로 직전에 작성한 Access Token의 문제점과 Refresh Token 글에서 Refresh Token이 무엇인지 글로 알아보았다. 하지만, 글만 읽어서는 공부를 끝냈다고 할 수 없다. 실제로 코드를 작성해야 지식을

hudi.blog

 

 

JWT signature does not match locally computed signature. JWT validity cannot be asserted and should not be trusted 에러가 발생되는 경우

 

→ 해당 에러는 토큰 검증시 시간이 만료되거나 key가 변경되어 맞지 않을때 발생되는 문제이다.

토큰값이 일치하는지, 토큰이 유효한지, 혹은 서버가 내려간건 아닌지, DB가 날라가진 않았는지 확인해보자 ! 

1. 어려웠던 부분 : 백엔드 스코프가 여전히 부족한 것 같아 아래와 같은 추가적인 기능을 계획했다. 

  • CI/CD
  • Refresh Token
  • S3 이미지 업로드
  • 업적 로직

이 중 Refresh Token 기능을 맡았는데, 구글링 해보니 나오는 예제들은 너무 많지만 대부분의 예제들이 MySQL에 토큰을 저장하는 거였고 Redis 스토리지를 활용한 예제는 찾을 수없어서 그 부분을 작성하는데 어려움이 있었다. 다행히 현재 Redis를 담당하고 계신 팀원분이 도와주셔서 해결할 수 있었는데, 공부가 더 필요할 것 같다. 

 

2. 느낀 점 : 프론트엔드와 디자이너분께 부담이 덜 가면서 백엔드의 스코프를 늘릴 수 있는 방법은 결국 인프라 부부을 향상시키는 방향인 것 같다. 그렇다면 지금 이 프로젝트에서 잘 써먹을 수 있는 것들은 뭐가 있을까? 일단 생각나는 키워드는 깃헙액션, 무중단배포, https (이 부분은 프론트엔드도 같이 해야함), 도커사용 ... 등이 있을 것 같다. 이번 프로젝트 덕분에 코딩하는 것 뿐만 아니라 프론트엔드, 디자이너, 백엔드가 서로를 배려하고 적절히 의견을 조율하는 방법을 배울 수 있는 것 같다.

 

3. 새로 알게 된 내용 : 자꾸 Redis를 조회할 때 알아보기 힘든 형태로 깨져서 출력이 되는데, 이를 해결해주는 Redis GUI 프로그램인 Medis가 있다는 것을 알았다. 바로 앱스토어에서 구매하면 $5정도 차감되고, 깃헙에 올라온 오픈소스는 무료인데, 이 오픈소스는 npm이라는 것을 또 설치해야 했다. 너무 번거로워서 찾아보던 중 3조 분이 CrudRepository 라는 것을 이용해 깔끔한 조회화면을 볼 수있다는 사실을 귀뜸해 주셨다. Redis를 맡은 팀원분이 적용해서 보여주셨는데, 정말 신기하게도 바로 깨지지 않는 화면이 나왔다. 

 

4. 셀프칭찬 (오늘 잘한 일) : Rfresh Token 기능 구현을 하루만에 성공했다. 물론 어려운 작업은 아니지만, 그래도 배우지 않은 부분을 구글링과 깃헙 자료를 통해 스스로 구현할 수 있어서 기뻤다 ! 

 

5. 내일 할 일 : 끝나지 않는 WebRTC 해결해 보자  ㅜㅜ ! 팀원 모두 붙어서 해결하는 중 ...


[오늘 공부한 부분] 

 

[05] Hashmap을 JSON으로 변환하는 법

1. JSONObject() JSONObject()를 호출 한 다음 해시 맵을 전달하는 방법 의존성 추가 // build.gradle 의존성 추가 부분 JsonObject implementation group: 'org.json', name: 'json', version: '20090211' import org.json.simple.JSONObject; i

leejincha.tistory.com

[48] 트러블슈팅 : No serializer found for class (Spring Boot) 해결못함 ^_^

 

[48] 트러블슈팅 : No serializer found for class (Spring Boot) 해결못함 ^_^

문제상황 WebRTC를 이용해 프론트엔드와 화상채팅을 구현하는 코드를 작성 중이다. 채팅방에 들어오는 사람마다 session ID를 갖고있는데, 이 세션 아이디를 Redis DB에 저장하는 과정에서 아래와 같

leejincha.tistory.com

[06] Spring Security 인증인가 - 예외 커스텀 핸들링

 

[06] Spring Security 인증인가 - 예외 커스텀 핸들링

이번 포스트는 Custom한 예외처리 (StatusCode)를 이용하여 JWT토큰에 관련된 예외처리를 작성한 부분을 담으려 한다. ExceptionTranslationFilter ExceptionTranslationFilter는 2가지 종류의 예외를 처리 FilterSecurityI

leejincha.tistory.com

[07] 1주차 기술멘토링 피드백 정리

 

[07] 1주차 기술멘토링 피드백 정리

1. 사전 준비 ① 노션 : https://www.notion.so/1-882180dd274943b683676575e8aae4dd 1조 기술멘토링 사전노트 코드 컨벤션 www.notion.so ② 준비한 질문 GameSet에서 발언권이 바뀔 때 마다 DB에 접근을 해야될 것 같은

leejincha.tistory.com

 

 

 

1. 어려웠던 부분 : 백엔드는 WebRTC를 제외하고 추가로 잡은 스코프까지 기능구현이 완료된 상태라 오늘부터 같이 WebRTC를 해결해보자는 의견이 나왔다. 그런데 내가 맡았던 부분이 아니라 너무 개념이 부족해서 일단 개념을 다시한번 잡아야 겠다는 생각이 들었다. 오늘은 비교적 여유가 있는 날이라 지난주 부터 정리하고 싶었던 여러 개념들을 블로그에 정리하면서 공부하는 시간을 가져보았다. 여러 참고 자료들을 보면서 공부를 하긴 하는데, 읽으면 이해는 되지만 내 머리에 저장이 되고있는 것 같지는 않아서 어떻게 하면 효율적으로 공부할 수 있을지 고민되는 하루였다.

 

2. 느낀 점 : 오늘 프로젝트의 핵심 기능인 WebRTC가 너무 해결이 안되고 있고, 또 대부분의 예제들이 Spring 이 아닌 Node.js를 사용한 예제 이기 때문에 그 예제를 ChatGPT라는 프로그램을 사용하여 Spring 으로 바꿔보는 시도를 해봤다. 물론 정확한 결과를 주진 않았지만 AI가 얼추 비슷한 코드를 죽죽 써내려 가는것을 보니, 아 이제 개발자 밥그릇도 줄어들겠구나라는 생각이 들었다. 외국어를 전공했더니 구글번역기가 다먹어버리고 ㅎ 개발을 시작했더니 ChatGPT가 등장했다. 긍정적으로 생각하자면, 잘 활용할 수 있는 사람이 된다면 더 효율적인 코딩을 하는 개발자가 될 수 있지 않을까 라는 생각을 했다.

 

3. 새로 알게 된 내용 : 이번 프로젝트에 유난히 Enum을 많이 사용하게 되었는데, 정확한 개념을 몰라서 정리해보는 시간을 가졌다. 그리고 지난주에 두번째 숙제로 받은 Git 과 Github 그리고 Gitflow에 대한 공부를 했다. 내용은 아래 링크 참조 ! 

 

4. 셀프칭찬 (오늘 잘한 일) : 내가 맡은 일을 끝내고 부족한 공부를 하는 나를 칭찬한다. 아직 많이 부족한거 같아서 불안하기도하고, 이번 프로젝트에서 너무 맡은 부분이 적은것 같아 걱정이 되기도 한다. 그렇지만, 이럴수록 전반적인 프로젝트를 심도있게 이해하자는 생각을 했다. 시간이 빌때마다 틈틈히 개념공부를 열심히 해서 어떤 면접 질문에도 잘 대답할 수 있도록 해야지 !  

 

5. 내일 할 일 : 아직도 시그널링 부분에 에러가 많다. 그 부분을 같이 해결해보기, 백엔드에선 추가적인 스코프 계획을 잡기 ! 

 


[오늘 공부한 부분] 

 

ChatGPT !! 엄청나다 !!

 

ChatGPT !! 엄청나다 !!

요즘 노마트코더를 비롯한 개발자들의 유튜브 채널에 자주 등장하는 화제인 ChatGPT! 코드도 작성해주고, 만든 코드를 개선시켜 주기도하고, 다른 언어로 바꿔주는 등 인공지능으로 다양한 서비

leejincha.tistory.com

[45] Git vs Github vs Git Flow

 

[45] Git vs Github vs Git Flow

Git vs GitHub Git Git is a distributed version control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals includ

leejincha.tistory.com

[02] Redis 설치 및 명령어 정리

 

[02] Redis 설치 및 명령어 정리

Redis 란? Redis 는 Key-Value 형태로 데이터를 관리하는 오픈 소스이다. Redis 는 빠른 속도와 간편한 사용법으로 인해 캐시, 인증 토큰, 세션 관리 등등 여러 용도로 사용되고 있다. Redis는 빠른 속도 대

leejincha.tistory.com

[03] (Spring Boot) WebSocket / WebRTC

 

[03] (Spring Boot) WebSocket / WebRTC

WebSocket 일반적인 클라이언트와 서버의 소통방식은 HTTP/HTTPS 통신을 거친다. 이는 클라이언트가 서버에 요청을 보내면 서버가 요청에대한 응답을 보내주는 구조이다. 실시간으로 채팅을 주고받

leejincha.tistory.com

[04] 카카오 로그인 PostMan 테스트 방법

 

[04] 카카오 로그인 PostMan 테스트 방법

※ 이 게시글은 카카오 로그인 코드가 구현되어 있다는 전제하에 PostMan으로 테스트 하는 방법을 담은 글 입니다 :) 1. 사전 준비 ( kakao developers) https://developers.kakao.com/ 위 사이트 접속 - [내 애플리

leejincha.tistory.com

[46] 트러블 슈팅 : InvaliDataAccessApiUsageException: detached entity passed to persist

 

[46] 트러블 슈팅 : InvaliDataAccessApiUsageException: detached entity passed to persist

문제상황 PostMan으로 게임방 생성하는 API를 테스트하는데 다음과 같은 에러가 발생했다. 회원탈퇴 기능을 추가한 후, 회원이 탈퇴하더라도 피드백 게시판의 글은 그대로 보존하기 위해, 아래와

leejincha.tistory.com

[47] Enum

 

[47] Enum

이번 프로젝트에 WebSocket/Stomp 를 이용해 채팅기능을 구현하면서 프론트에 전달하는 messageType에 Enum을 사용하게 되었다. 내가 구현한 코드부분이 아니기도하고 Enum에 대한 개념이해가 부족해서

leejincha.tistory.com

 

+ Recent posts