팀과제- React 심화주차

1.

s3 버킷에 배포한 뒤, 어떤도메인.com이 아닌 어떤도메인.com/login 등 페이지로 이동하면 왜 오류가 날까요?

404 (Not Found)

리액트를 아무런 처리없이 빌드하고 배포하고 나서, 특정 URL로 바로 접근 시 생기는 에러

리액트라서 생기는 문제이라기 보다 SPA이 가진 특징 때문에 생기는 문제

왜 이런 에러가 발생 하는가

s3 버킷의 정적 웹사이트 호스팅은 /login 경로에 맞는 html을 찾는 거고, 해당 html파일이 없기 때문에 404 에러가 나는 것이다.

따라서, Base가 되는 URL이 아닌 다른 URL을 통해 사이트에 접속해도, index.html을 연결시켜 배포하는 작업이 필요

S3 서버에서의 처리 방법

S3에서는 정적 웹 사이트 호스팅 편집에서 인덱스 문서와 오류문서를 index.html 하나로 설정하면 해결

 

2.

리액트에서 각 페이지 컨텐츠에 맞는 미리보기(사이트 이미지, 사이트 설명 등)를 띄워주려면 어떻게 해야할까요?

리액트에서는 헬맷 라이브러리를 사용해서 웹페이지의 제목이나 이미지, 간단한 설명을 검색엔진에 알려주는 역할을 하는 메타 태그를 처리해 줍니다.

 

3.

리덕스에서 미들웨어 청크의 역할은 뭘까요?

액션 객체를 dispatch하는 대신 함수를 dispatch할 수 있도록 해줍니다. dispatch한 함수는 dispatch, getState, 그 외의 직접 설정한 값을 받아 사용할 수 있고 비동기 처리 등에 사용할 수 있다.

 

 

4.

프로미스는 정확히 말하면 비동기가 아닙니다. 비동기와 프로미스는 각각 무엇일까요?

Promise[프로미스]는 자바스크립트에서 비동기 처리에 사용되는 객체라고 한다. 비동기 처리는 코드 실행 후 결과를 받는것을 기다리지 않고 다음 코드를 계속 진행하는 처리 방식을 말한다.(동기 처리는 반대로 앞선 코드를 수행하고 그 결과를 받을 때 까지 기다린 다음에 수행하는 것을 말한다)

Promise 객체는

new Promis(function(resolve, reject)){
	// 코드
    resolve(response);
}

이런식으로 resolve, reject, then 함수 등이 있다

 

동기(synchronous : 동시에 일어나는)

-동기는 말 그대로 동시에 일어난다는 뜻입니다. 요철과 그 결과가 동시에 일어난다는 약속인데요. 바로 요청을 하면 시간이 얼마가 걸리던지 요청한 자리에서 결과가 주어져야 합니다.

• 요청과 결과가 한 자리에서 동시에 일어남
• A노드와 B노드 사이의 작업 처리 단위(transaction)를 동시에 맞추겠다.

비동기 (Asynchronous : 동시에 일어나지 않는)

-비동기는 동시에 일어나지 않는다를 의미합니다. 요청과 결과가 동시에 일어나지 않을거라는 약속입니다.

• 요청한 그 자리에서 결과가 주어지지 않음
• 노드 사이의 작업 처리 단위를 동시에 맞추지 않아도 된다.

동기와 비동기는 상황에 따라서 각각의 장단점이 있다.

동기방식은설계가 매우 간단하고 직관적이지만 결과가 주어질 때까지 아무것도 못하고 대기해야 하는 단점이 있고,

비동기방식은 동기보다 복잡하지만 결과가 주어지는데 시간이 걸리더라도 그 시간 동안 다른 작업을 할 수 있으므로 자원을 효율적으로 사용할 수 있는 장점이 있습니다.

 

5.

TDZ(Temporal Dead Zone/일시적 사각지대)란?

const, let은 선언할 때 선언 -> 초기화 단계를 거칩니다.
런타임(파일을 한 줄 한 줄 실행하는 것) 이전에 선언되어 메모리에 한 자리를 차지하지만 초기화 단계가 아직 실행되지 않았기 때문에 해당 변수(상수)에 접근할 수는 없는 상태를 TDZ라고 합니다.

 

 

6. 서버 기반 인증과 토큰 기반 인증

 

서버(세션)기반 인증방식

토큰 기반 인증이 없었을 때의 인증 시스템은 서버 측에서 유저들의 정보를 기억하고 있어야 했다.

서버 기반 인증 시스템의 흐름은 아래와 같다.

서버 기반 인증의 문제점

메모리 과부화

- 유저가 인증을 할 때, 서버는 이 기록을 서버에 저장해야 하는데 이를 세션이라고 한다. 대부분의 경우 메모리에 저장하는데, 유저의 수가 급격히 늘어난다면 서버의 램이 과부화된다.

- 이를 피하기 위해 데이터베이스에 저장하는 방식도 있으나 유저의 수가 많으면 데이터베이스 성능에 무리를 줄 수 있다.

 

확장성 문제

- 세션을 사용하면 서버를 확장하기 어려워 진다. 서버의 확장은 더 많은 트래픽을 감당하기 위하여 여러개의 프로세스를 돌리거나 여러대의 서버 컴퓨터를 추가하는 것을 의미한다.

 

CORS(Cross-Origin Resource Sharing)

- 웹 어플리케이션에서 세션을 관리 할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계 되었다. 따라서 쿠키를 여러 도메인에서 관리하는것은 좀 번거롭다.

 

토큰기반 인증방식

토큰기반 인증방식 작동 원리

- 토큰 기반 시스템은 stateless하다. 즉 상태유지를 하지 않는다. 이 시스템에서는 더 이상 유저의 정보를 서버나 세션에 담아두지 않는다.

 

이 개념만으로 위에서 서술한 서버 기반 인증 방식의 많은 문제점이 해소된다.

- 서버측 메모리 과부화 해소

- 세션이 존재하지 않으니 유저들이 로그인 되어있는 지 신경 쓰지 않으면서 서버를 손쉽게 확장

 

구현방식

토큰 기반 시스템의 구현 방식은 시스템마다 크고작은 차이가 있겠지만, 대략적으로 보면 다음과 같다.

1. 유저가 아이디와 비밀번호로 로그인을 한다
2. 서버측에서 해당 계정정보를 검증
3. 계정정보가 정확하다면, 서버측에서 유저에게 signed 토큰을 발급

• 여기서 signed 의 의미는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature 를 지니고 있다는 것

1. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때 마다, 해당 토큰을 함께 서버에 전달
2. 서버는 토큰을 검증하고, 요청에 응답합니다.

웹서버에서 토큰을 서버에 전달 할 때에는, HTTP 요청의 헤더에 토큰값을 포함시켜서 전달합니다.

 

토큰의 방식

1) 무상태(stateless)이며 확장성(scalability)

• 토큰은 클라이언트 사이드에서 저장하기 때문에 완전히 stateless하다 그렇기에 서버를 확장하기에 매우 적합한 환경을 제공한다

만약에 세션을 서버 측에서 저장하고 있고 서버를 여러대를 사용하여 요청을 분산하였다면 어떤 유저가 로그인 시 처음 로그인했던 그 서버에만 요청을 보내도록 설정을 해야한다. 하지만 토큰은 이 문제를 해결한다.

 

2) 보안성

클라이언트가 서버에 요청을 보낼 때 더 이상 쿠키글 전달하지 않음으로 쿠키를 사용함으로서 인해 발생하는 취약점이 사라진다.
(하지만 토큰을 사용하는 환경에서도 취약점이 존재한다)

 

3) 확장성(Extensibility)

Extensibility 는 로그인 정보가 사용되는 분야를 확장하는것을 의미. 토큰을 사용하여 다른 서비스에서도 권한을 공유 할 수 있다.

예를 들어서, 스타트업 구인구직 웹서비스인 로켓펀치에서는 Facebook, LinkedIn, GitHub, Google 계정으로 로그인을 할 수 있다

 

4) 여러 플랫폼 및 도메인

• 어플리케이션과 서비스의 규모가 커지면 우리는 여러 디바이스를 호환 시키고, 더 많은 종류의 서비스를 제공하게 되는데 토큰을 사용한다면, 그 어떤 디바이스, 도메인에서도 토큰만 유효하다면 요청이 정상적으러 처리된다.