회사다닐 때, 정리해두었던 자료를 늦게나마 블로그에 적어보려고합니다.

먼저, spread 문법과 map을 사용한 데이터 할당

// 1번
const newList = [...rawMemeberTypeList]; 

// 2번
const newList = rawMemberTypeList.map((item) => {...item});

Q. 1번은 어떻게 복사가 될까요?

A. 얕은 복사로서, "newList"는 "rawMember..." 와 같은 배열 요소를 참조합니다.
기존의 배열 "rawMember" 과 새로운 "newList" 중 하나를 수정하면 다른 배열에도 영향을 미친답니다.

Q. 2번은 어떻게 복사가 될까요?

A. 깊은 복사로서, map 함수를 통해 "rawMemberTypeList" 의 각 요소를 복사하여 새로운 배열 "newList" 를 생성합니다.
이렇게 하면 "newList"와 "rawMemberTypeList" 의 복제본이므로 두 배열은 독립적으로 존재합니다.
기존 "rawMember..." 나 "newList" 중 하나를 수정해도 다른 배열에 영향을 미치지 않습니다.

인증과 인가

Q. 인증(Authentication)과 인가(Authorization)란 무엇인가요?

A. 인증(Authentication)은 사용자가 본인이 주장하는 대로 자신임을 인증하는 과정입니다. 일반적으로 아이디와 비밀번호를 입력하여 로그인하는 것이 인증의 예입니다. 반면, 인가(Authorization)는 인증된 사용자가 특정 자원이나 기능을 사용할 수 있는 권한이 있는지 확인하는 과정입니다. 예를 들어, 일반 사용자가 관리자 페이지에 접근하는 것은 인가되지 않은 것입니다. 인가는 일반적으로 역할(Role)과 권한(Permission)을 기반으로 수행됩니다. 역할은 사용자 그룹을 의미하며, 권한은 해당 역할에 대해 부여된 권한을 의미합니다. 즉, 역할을 기반으로 권한을 관리하여 인가를 수행합니다.

Q. 왜 인증 방식이 필요한 가요?

A. HTTP의 비연결성과 비상태성이라는 특성 때문에 인증 방식이 필요합니다.

Session이란?

• Session은 사용자의 상태를 관리하는 기술로, 같은 사용자로부터 일련의 요청을 하나의 상태로 유지시키는 것입니다. 연결은 방문자가 웹 브라우저를 종료함으로써 끝납니다.
• HTTP의 비연결성과 비상태성으로 인해 인증 방식이 필요합니다. 인증은 사용자가 본인이 주장하는 대로 자신임을 인증하는 과정이고, 인가는 인증된 사용자가 특정 자원이나 기능을 사용할 수 있는 권한이 있는지 확인하는 과정입니다.
• 세션과 쿠키는 인증 문제를 해결하기 위해 사용됩니다. 세션은 서버에서 사용자의 상태를 관리하고, 쿠키는 클라이언트에서 사용자의 상태를 관리합니다. 세션은 보안성이 높지만, 서버 자원을 많이 사용합니다. 쿠키는 보안성이 낮을 수 있지만, 서버 자원을 적게 사용합니다.

Cookie란?

• 쿠키(Cookie)는 클라이언트 측에서 사용자의 상태를 관리하는 기술로, 브라우저에 저장됩니다. 서버에서 응답(Response)을 보낼 때, Set-Cookie 헤더를 사용하여 클라이언트에게 쿠키를 전송할 수 있습니다. 그러면, 클라이언트는 이후 요청(Request)에서 해당 쿠키를 서버에게 전송하여 사용자의 상태를 유지시킬 수 있습니다.

JWT란?

• JWT(Json Web Token)는 웹 표준으로 지정된 JSON 기반의 토큰입니다. JWT는 클라이언트와 서버 간의 정보를 안전하게 전송할 수 있도록 해줍니다. JWT는 페이로드(Payload)와 시그니처(Signature)로 구성되어 있으며, 페이로드는 정보를 담고 있고, 시그니처는 해당 정보가 유효한지 확인하는 데 사용됩니다. JWT는 세션과 쿠키와 같은 인증 방식을 대체하여 사용될 수 있습니다.
• 왜 JWT를 사용하는가?이 방법은 HTTP 프로토콜을 사용하여 통신을 합니다.
  1. Conncetionless ⇒ 연결을 유지하지 않는다.
  2. Stateless ⇒ 상태를 유지하지 않는다.
  3. : 서버와 클라이언트는 첫번째 통신을 하고 나서 두번째 통신을 할 때는 이전의 통신에 대한 정보를 가지고 있지 않음. → 즉, 새롭게 갱신을 해줘야함.그렇다면 로그인은 어떻게 처리를 해줘야 할까요?
  4. 로그인 처리 방법
  5. : 서버와 클라이언트가 한번 통신이 일어나고 나면 그 연결이 유지가 되는 것이 아니라 바로 끊어짐.
  6. DB에 USER ID와 PASSWORD 비교하여 로그인하기
     • 이 방법은 로그인 유지가 안될 뿐더러 정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 해주거나 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 일이 발생 할 수 있음.
     • Sessiong(세션) 과 Token(토큰)세션 방식 → 서버의 메모리, 데이터베이스와 같은 서버의 자원들을 사용해서 사용자의 정보를 유지시키는 방식임.토큰 방식서버에 저장하지 않아서 서버에 확장성이 있음.
  7. 위에서 말한것처럼 로그인을 했을 때 해당 서버에만 요청을 보내는 것이 아닌 요청이 들어왔을 때 해당 토큰이 유효한지만 체크하면 됨.
  8. 토큰 방식은 사용자가 로그인을 하면 서버에서 발행해주는 토큰을 가지고 브라우저의 저장소에 토큰을 유지시키는 방법임. 여기서 말하는 토큰이 우리가 말하고자하는 JWT임.
  9. 토큰보다 보안에 강하다는 장점이 있지만 단점으로 서버의 확장성이 떨어지고, 서버의 자원(세션을 저장, 유지할 공간) 이 많이 필요함. 또한 세션이 서버에 저장이 되고, 트래픽 분산을 위해 여러대의 서버를 사용할 때, 만약 사용자가 로그인을 했을 때는 만들어진 세션을 참조해야 하기 때문에 처음 로그인한 그 서버에서만 요청을 보내야한다는 단점이 있음.
• HTTP 프토토콜은 두 가지 특성이 있습니다.
• “로그인” 이라는 과정은 “서버와 클라이언트가 데이터를 주고 받는 통신 방법”이 필요합니다.
• JWT란?
  • 구성
    • Header
    • JWT를 검증하는데 필요한 정보를 가진 JSON을 BASE64 알고리즘 기반으로 인코딩한 문자열이며 검증을 하기 위한 내용을 가지고 있음.
    • Payload
      • Payload는 암호화되지 않기때문에 비밀번호와 같은 민감한 값을 넣으면 안됨.
    • JWT에 저장된 값이며, (name,value)의 쌍으로 이루어져 있고, JWT에는 이 값들을 여러개 할당할 수 있음.
    • Signature
    • JWT를 인코딩하거나 유효성 검증을 할 때 사용하는 암호화된 코드임.
  • Header - Payload - Signature
• JWT는 Client 와 Server 사이 통신 시 권한을 인가하기 위해 사용하는 토큰임.

RefeshToken과 AccessToken 의 관리는 고려...

 유지보수 도중, 기존의 Row Query가 이해가 안가는 부분이 있어 생각하고 직접 사용해보며, 그 차이를 정리하고자합니다.

"INSERT ... ON DUPLICATE KEY UPDATE"  는 MySQL에서 사용되는 쿼리 구문
특정한 유니크 또는 프라이머리 키 제약 조건을 가진 테이블에 데이터를 추가하려고 할 때, 
이미 해당 키가 존재하면 기존 행을 업데이트하고 그렇지 않으면 새로운 행을 삽입함.

INSERT INTO table_name (column1, column2, ...)
VALUES (value1, value2, ...)
ON DUPLICATE KEY UPDATE column1 = value1, column2 = value2, ...;

- table_name: 데이터를 삽입할 테이블의 이름
- (column1, column2, ...): 삽입될 열의 이름 목록
- (value1, value2, ...): 삽입될 값의 목록
- ON DUPLICATE KEY UPDATE: 유니크 또는 프라이머리 키 충돌 시 실행되는 업데이트 부분
- column1 = value1, column2 = value2, ...: 충돌 시 각 열에 대해 업데이트할 값을 지정

"INSERT IGNORE" 는 MySQL에서 사용되는 쿼리 구문, 데이터를 특정 테이블에 삽입하고 할 때,
유니크 또는 프라이머리 키 충돌 등의 이유로 삽입이 불가능한 경우 해당 행을 무시하고 계속 진행함.

INSERT IGNORE INTO table_name (column1, column2, ...)
VALUES (value1, value2, ...);

- table_name: 데이터를 삽입할 테이블의 이름
- (column1, column2, ...): 삽입될 열의 이름 목록
- (value1, value2, ...): 삽입될 값의 목록
- IGNORE: 유니크 또는 프라이머리 키 충돌이 발생하더라도 해당 행을 무시하고 진행

어떤 것을 어느 상황에서 사용해야할까요?
성능적인 측면에서 봤을 땐, 어떤 것이 더 좋을까요?

"INSERT ... ON DUPLICATE KEY UPDATE"
 - 중복된 키 충돌이 발생했을 때 업데이트를 수행하는 경우
 - 특정 열을 업데이트하거나 추가적인 처리를 수행하는 경우
 - 중복이 발생할때 마다 추가적인 업데이트 작업이 수행되므로 오버헤드가 발생할 수 있음

"INSERT IGNORE"
 - 중복된 키 충돌이 발생했을 때 무시하고 계속 진행하는 경우
 - 추가적인 업데이트 또는 변경이 필요하지 않은 경우
 - 중복 발생 시 단순히 무시하므로 추가적인 작업이 없어 성능이 위에보다 좋을 수 있음

안녕하세요.
오늘은 Redis를 이용한 AccessToken과 RefreshToken 관리 방법에 대해 정리하려고합니다.

[기존의 제가 사용하던 방식]

유저가 로그인을 하는 경우
AccessToken은 Response로 Client (Front or Android...) 에게 전달
RefreshToken은 Redis에 저장

이렇게 한 이유
"RefreshToken이 RDB(MySQL, ...) 에 저장되면 Session과 뭐가 다른게 있을까?" 생각 때문이었습니다.
만약, RefreshToken이 RDB에 저장되는 경우
AccessToken이 만료가 되는 경우, RefreshToken을 DB에 접근을 하면서 DB자원을 사용하는 것이 마음에 들지 않아...
Redis를 사용하였습니다.

고치게 된 이유
정리를 하는 중에, 이 방식도 보안적으로 문제가 있다고 생각이 들었습니다.
이 주제로 고민과 주변 개발자분들에게 조언을 얻어...

[새로운 방식]

유저가 로그인을 하는 경우
AccessToken은 Response로 Client (Front or Android...) 에게 전달.
AccessToken은 Redis에 저장.
RefreshToken은 암호화하여 RDB에 저장.
만약, AccessToken이 만료되는 경우
RefreshToken은 RDB에서 조회 유효한지 확인.
RefreshToken이 사용되면 새로운 RefreshToken이 발급되어 RDB에 저장.

이렇게 한 이유
기존 사용하던 방식보다는 안전한 방식이라고 생각이 들었습니다.

간략하게 정리...

AccessToken, RefreshToken 란?

AccessToken (액세스 토큰) 
- 역할 : 사용자가 인증된 후 서비스에 접근할 때 사용되는 토큰.
- 수명 : 보통 짧은 수명을 가지며, 특정 시간이 지나면 만료됩니다.
- 획득 방법 : 사용자가 로그인하면 서버에서 발급되고, 이를 클라이언트가 HTTP 헤더 등에 실어서 API 요청 시 함께 보내어 인증함.

RefreshToken(리프레시 토큰)
- 역할 : AccessToken이 만료되었을 때 새로운 AccessToken을 발급받을 수 있는 권한을 부여하는 토큰.
- 수명 : AccessToken보다 상대적으로 긴 수명을 가지며, 안전한 방식으로 저장되어야함.
- 획득 방법 : 사용자가 로그인 시 함께 발급되며, AccessToken이 만료되었을 때 서버에 보내져 새로운 AccessToken을 받음.

Redis 란?

Redis
- 역할 : 데이터를 캐싱하고 저장하기 위한 오픈 소스 인메모리 데이터 구조 저장소임.
- 활용 : 토큰, 세션, 캐시 등을 저장하는 데 사용됨.
- 특징 : 빠른 속도와 메모리 기반이기 때문에 인증 토큰을 안전하게 저장하고 빠르게 검색할 수 있는 용도로 활용됨.

 실무를 하다보니.. 새로운 것을 만들기보다는 기존에 있던 것을 유지보수 하거나 기능을 추가하는 일이 많습니다.
아무래도 새로운 모듈을 추가하거나 새로운 것을 처음부터 개발하는 경우는 많이 없었습니다.
 그래서 잊고지내던 친구들을 다시 보고싶어 정리를 결심하게 되었습니다.

1. Node 프로젝트의 'devDependencies' 와 'dependencies' 의 차이.

   1) dependencies (의존성) 
     : 이 카테고리에 있는 패키지는 프로덕션 환경에서 실행될 때 필요한 패키지입니다.
     즉, 실제로 애플리케이션이 동작할 때 사용됩니다. 이러한 패키지들은 애플리케이션의 핵심 로직을 지원하거나 실행에 필수적인 라이브러리임.

    -> 이게 뭔말이냐.. npm install express 를 하면 express 모듈을 사용해서 서버를 구축하잖아요?
그럼 이건 프로덕션 환경(실제 서비스) 에서 사용되는 것이기 때문에 dependencies 에 속하게 되는 거죠..

  2) devDependencies (개발 의존성)
    : 이 카테고리에 있는 패키지는 주로 개발 환경에서 개발자의 작업을 돕거나 테스트, 빌드, 디버깅 등을 지원하는 도구나 라이브러리임. 
    즉, 이러한 패키지들은 실제 프로덕션 환경에서 필요하지 않으며, 주로 개발자가 코드를 작성하고 테스트하는 동안 사용됨.

  -> 이건... 많이들 사용하시는 npm install rand-token  nodemon --save-dev 를 사용하는 경우죠.
그럼 대개 뭐가 있냐.. 위에서 install 한 라이브러리들이 대개 개발자의 작업을 돕는 도구나 라이브러리가 되는 것이죠.

1. 공유기 포트 포워딩

공유기에 설정된 192.168.% 으로 시작하는 ip에 접속하여 포트포워딩.

서비스 포트에 외부에서 연결 시, 사용할 포트 
내부 IP 주소 : cmd -> ipconfig 해서 나오는 ip와 사용하고싶은 프로그램 포트.
   ex)  사용하고 싶은 프로그램 포트 : cmd netstat 를 통해 mysql을 사용하고 싶은 경우 3306 포트를 작성.

2. Window 10 에서 방화벽 인바운드 규칙 설정하기.

 - 윈도우 > 검색 : 방화벽 > 고급 설정 

 - 인바운드 규칙에서 사용할 프로그램 위치에서 exe 파일 설정.

추가) 위의 경우 내부망(사설 IP)에서만 접근 가능합니다!

3. Mysql 에서 권한주기.

1. root 계정으로 접속하기
   1) Terminal 로 mysql -u -p 로 접속하기
   2) MySQL Workbench 로 접속하기

2. 2)를 선택하여 진행하는 경우,
   1) CREATE USER 'TEST'@'localhost' IDENTIFIED BY '1234' ;
      CREATE USER '<유저명>'@'<유저IP>' IDENTIFIED BY '<비밀번호>';
   
     => 유저 생성하기.

   2) GRANT all privileges on *.* to 'TEST'@'localhost' identified by '1234';
      GRANT all privileges on <데이터베이스명>.* to '<유저명>'@'<유저IP>' identified by '<비밀번호>'

     => 유저IP에 해당하는 유저명 접근 허용 설정

   3) flush privileges;
     
     => 현재 사용중인 MySQL의 캐시를 지우고 새로운 설정을 적용하기 위해서 사용되는 명령어 


AWS 프리티어로 내부에 DB를 달고 진행 중, 관리를 하지 않아 비용이 많이 청구된 것을 확인한 뒤... AWS 프리티어만을 고집하기 보단.. 내 컴퓨터에서 DB를 저장하고 싶은 생각이 들어서 설정하다가 정리하게 되었습니다.

GRANT는 실무에서 사용하지 않는 경우가 많다고 합니다. 보안상의 문제로.. 시간이 되면 더 자세하게 찾아서 정리해보죠.