[내일배움캠프] 최종 프로젝트 Day 28 | Node.js 4기 | Day 109 | 24.04.22.(월)

jwt token .. 페이로드 ..

 

몇 번으로 로그인하든 동일하게 가는지 봐야 하고 ..

 

payload.email .. 

 

—

 

1. 이메일이 null로 가는 게 가장 큰 문제.

 

1. payload가 제대로 안 온다는 뜻.

 

왜 안 오는지는 디버깅 같이 하시구요

 

이메일이 null인게 있으면 안 되고 ..

 

이메일이 왜 null인지 파악하고 

 

 

payload .. 토큰에 사용자 정보를 담기 위한 것 ..

 

데코레이터랑 DTO가 다른 거야?

뤼튼
GPT-4

네, 데코레이터(Decorator)와 DTO(Data Transfer Object)는 서로 다른 개념입니다.

DTO (Data Transfer Object):

DTO는 계층 간 데이터 교환을 위해 사용되는 객체입니다.
주로 데이터베이스에서 데이터를 가져온 후 서비스나 클라이언트에 전달할 때 사용되며,
여러 데이터 필드를 하나의 객체로 묶어 관리하기 위한 목적으로 사용됩니다.
DTO는 데이터의 전송 및 수신에 초점을 맞추며, 로직을 포함하지 않고 순수한 데이터 구조로만 구성됩니다.

데코레이터 (Decorator):

데코레이터는 디자인 패턴의 하나로, 객체에 추가적인 책임을 동적으로 추가하는 패턴입니다.
프로그래밍에서는 특히 TypeScript나 JavaScript와 같은 언어에서 함수나 클래스, 속성 등에
특별한 의미나 기능을 선언적으로 추가할 수 있는 구문입니다.
데코레이터는 실행 시간에 코드에 추가적인 기능을 부여하거나,
NestJS와 같은 프레임워크에서 특정 메타데이터를 설정하는 용도로 사용됩니다.

두 개념의 차이점:
* 목적: DTO는 데이터를 효율적으로 전송하기 위한 구조체로 사용되며,
데코레이터는 기존 코드에 추가적인 기능이나 메타데이터를 부여하기 위해 사용됩니다.
* 사용 방식: DTO는 일반적으로 클래스로 정의되어 데이터의 구조를 나타내지만, 로직을 포함하지 않습니다.
반면, 데코레이터는 특정 대상(클래스, 메서드, 속성 등)에 대해 선언적으로 적용되어 그 대상의 동작을
확장하거나 변경합니다.
* 적용 분야: DTO는 주로 애플리케이션의 서비스 계층과 프레젠테이션 계층 사이에서
데이터를 전달하는 데 사용됩니다.
데코레이터는 객체 지향 프로그래밍 및 함수형 프로그래밍의 다양한 분야에서 코드의 재사용성을 높이고,
코드를 더 간결하게 만들기 위해 사용됩니다.
따라서 데코레이터와 DTO는 서로 다른 목적과 사용 방식을 가지고 있으며,
각각의 개념을 적절히 이해하고 사용하는 것이 중요합니다.

 

발표회 하기 전에 한번 .. 

 

수요일까지 프론트 마무리하기로 했으니까 .. 

목요일에 유저 테스트 하고 .. 

 

수요일 저녁까지 하는 거로 .. 

 

 

프로필 설정할 때 이런 오류가 발생하는 것 같다.

그렇다면 프로필 설정을 하지 않고 미션 생성하고 사진 인증하고 해보면 어떨까?

인증 메일 발송 누르고 회원가입 하면 이미 회원가입된 이메일이라는 표시가 뜨는데,
인증 메일 발송되는 순간에 회원가입이 되는 건지 체크할 필요가 있을 것으로 보인다.
-> 실제로 이미 회원가입이 되었기 때문.

 

 

query failed: SELECT `User`.`user_id` AS `User_user_id`, `User`.`email` AS `User_email`, `User`.`name` AS `User_name`, `User`.`nick_name` AS `User_nick_name`, `User`.`password` AS `User_password`, `User`.`image` AS `User_image`, `User`.`provider_id` AS `User_provider_id` FROM `users` `User` WHERE ((`User`.`email` = ?)) LIMIT 1 -- PARAMETERS: ["sjwoo1999@gmail.com"]
error: Error: Table 'lifebit.users' doesn't exist
[Nest] 8536  - 2024. 04. 22. 오후 2:19:32   ERROR [ExceptionsHandler] Table 'lifebit.users' doesn't exist

 

로그아웃하지 않고 새로운 사용자로 로그인하는 경우에 refreshToken 재설정이 원활하게 되지 않아서 
문제가 발생할 가능성이 있을까? 미친 디테일로 설명해줘봐.

네, 로그아웃을 하지 않고 새로운 사용자로 로그인할 때 refreshToken의 재설정과 관련하여 문제가 발생할 가능성이
있습니다. 여기서 발생할 수 있는 주요 문제점들과 그에 대한 자세한 설명은 다음과 같습니다.

1. 이전 사용자의 refreshToken 유출 위험

만약 사용자 A가 로그아웃을 하지 않고 시스템이 사용자 B로 로그인 처리를 할 때,
사용자 A의 refreshToken이 여전히 유효한 상태로 남아있게 됩니다.
이 경우, 악의적인 사용자가 이 refreshToken을 가로채거나 유출된 경우를 가정할 때,
사용자 A의 계정에 계속 접근할 수 있는 위험이 발생합니다.

2. refreshToken 관리 복잡성 증가

서버에서는 각 사용자별로 refreshToken을 관리해야 합니다.
사용자가 로그아웃하지 않고 다른 사용자로 로그인하는 경우,
이전 사용자의 refreshToken을 어떻게 처리할지 결정해야 합니다.
예를 들어, 같은 장치에서 여러 사용자가 번갈아 가며 사용하는 경우,
각 사용자의 refreshToken을 어떻게 분리하여 관리할지에 대한 로직이 복잡해질 수 있습니다.

3. 사용자 인증 상태 혼란

사용자 A가 로그아웃하지 않고 사용자 B로 로그인하는 경우, 사용자 A의 refreshToken이 여전히 유효하면서,
사용자 B의 refreshToken도 동시에 생성되고 관리되어야 합니다.
이러한 상황에서 시스템이 두 사용자의 인증 상태를 정확히 구분하지 못하고 혼란을 겪을 수 있으며,
이는 보안 문제로 이어질 수 있습니다.

해결 방안
1. 토큰 블랙리스트 관리: 로그아웃하지 않고 새로운 사용자로 로그인하는 경우,
이전 사용자의 refreshToken을 블랙리스트에 추가하여 더 이상 사용할 수 없도록 처리합니다.
이 방법으로 이전 사용자의 refreshToken 유출 위험을 줄일 수 있습니다.
2. 디바이스별 토큰 관리: 사용자가 로그인할 때,
특정 디바이스를 식별할 수 있는 정보(예: 디바이스 ID)를 함께 제출하도록 하여,
각 디바이스별로 refreshToken을 관리합니다. 이를 통해 여러 사용자가 동일한 디바이스를 사용하는 경우에도
각 사용자의 refreshToken을 명확히 구분할 수 있습니다.
3. 세션 타임아웃 설정: 일정 시간 동안 활동이 없는 경우 자동으로 사용자의 세션을 만료시켜 로그아웃 처리하는
방법을 적용할 수 있습니다. 이는 refreshToken이 유출되었을 때 잠재적인 피해를 줄이는 데 도움이 됩니다.

이러한 방법들은 refreshToken 재설정 과정에서 발생할 수 있는 문제를 최소화하고,
시스템의 보안을 강화하는 데 기여할 수 있습니다.

 

드디어!!!

 

 

 

 

Modified: User, Point, CertificatedImage

 

User - Point | 1:1 연결

vision.service에서 이미지 인증하면 사용자에 연결된 포인트 값이 증가함

point 객체를 포인트 로그를 확인할 수 있음.

현재 추가된 값, 전체 포인트 값을 갖고 있음.

다른 계정으로 로그인 했을 때 각 계정에 대한 포인트 값이 증가하지 않는 문제가 있었으나
payload에 email 값을 추가해줌으로써 해당 문제 해결

 

 

 

 

 

 

 

 

 

프론트 초기 세팅 완료!