거니의 velog

* 최근의 앱과 웹에서는 전통적인 회원가입 방식을 대신해서 흔히 소셜 로그인이라고 부르는 제3자 인증 방식으로 하는 경우가 많다. 예를 들어 구글이나 네이버, 애플, 페이스북 등의 서비스를 이용해서 별도의 회원가입 없이 로그인을 처리하는 방식이다. * 이번 장에서는 리액트와 API 서버를 연계해서 리액트에서 카카오 서비스의 로그인을 호출하고, API 서버에서는 사용자의 인증 정보를 이용해서 기존 회원 데이터와 연동하도록 구성해 본다. * 이번 장의 개발 목표는 다음과 같다.1. 소셜 로그인 방식의 이해 2. 카카오 로그인을 위한 설정 3. 리액트에서 사용자 인증 4. API 서버의 사용자 처리1. 소셜 로그인과 OAuth2.0* 소셜 로그인은 기존의 서비스와 달리 제3의 사용자 인증 서비스를 이용해서 현..

5. Axios 인터셉터와 Refresh Token * 로그인에 대한 저장과 애플리케이션 내의 상태 유지가 완료되었지만, API 서버의 호출에는 JWT 방식으로 Access Token 때문에 정상적으로 실행되지 못한다. API 서버의 /api/todo/ 혹은 /api/products/ 로 시작하는 경로를 호출했을 때는 에러가 발생하는 것을 볼 수 있다. * API 서버는 Access Token을 체크하기 때문에 Axios의 호출 시에 Access Token을 전달해야만 한다. 또한, Access Token이 만료되었을 때는 Refresh Token으로 Access Token을 갱신하는 처리가 필요하다. * Axios의 경우에는 인터셉터(interceptor) 기능을 제공해서 Axios의 요청이나 응답 시..

4. 쿠키를 이용한 애플리케이션 상태 저장 * 작성된 예제들은 로그인을 유지하거나 애플리케이션의 상태가 변경되는 상황에 대해서는 처리가 되지만, SPA의 근본적인 문제점인 '새로고침' 문제는 여전히 남는다. 로그인된 상황에서 브라우저의 '새로고침'을 호출하면 애플리케이션 자체가 다시 로딩되기 때문에 기존 애플리케이션의 상태 역시 초기화되는 문제가 발생한다. * 이를 해결하기 위해서는 브라우저 내에 애플리케이션의 상태 데이터를 보관하고 애플리케이션이 로딩될 때 저장된 정보들을 로딩해서 사용하도록 구성해야만 하는데, 이를 위해서 주로 LocalStorage나 쿠키를 사용할 때가 많다. 예제에서는 유효시간을 가지는 쿠키를 사용해서 로그인한 상태를 저장한다. * 리액트에서 쿠키를 사용하는 가장 간단한 방법은 r..

3. 비동기 호출과 createAsyncThunk() * useSelector() 와 useDispatch() 로 애플리케이션 상태를 이용할 때 필요한 또 다른 기능은 비동기 처리이다. 위의 예제는 API 서버를 통해서 로그인/로그아웃을 처리해야 하는 작업과 로그인 시에 API 서버를 연동한 처리가 필요하다. * 과거 리덕스의 경우 redux-thunk나 redux-saga라는 추가적인 라이브러리를 사용해서 비동기 처리를 했지만, 리덕스 툴킷은 createAsyncThunk() 라는 기능을 사용해서 비동기 통신 상태에 따른 처리가 가능하다. * API 서버와의 통신을 위해 프로젝트 내에 api 폴더 내에 memberApi.js 파일을 추가한다. import axios from "axios"; import..

(2) 로그아웃 페이지와 로그아웃 * 애플리케이션 상태에 email 값이 존재하면 로그인한 상황이라고 가정하고, 로그인 상황에서는 로그아웃 페이지로 이동할 수 있는 링크와 컴포넌트가 필요하다. * pages/member/LogoutPage.js를 작성하고 components/member/LogoutComponent.js를 작성한다. * LogoutComponent는 화면 상에 LOGOUT 버튼을 만들고 클릭하면 loginSlice의 로그아웃을 호출한다. import React from "react"; import { useDispatch } from "react-redux"; import { logout } from "../../slices/loginSlice"; const LogoutComponent ..

2. useSelector() / useDispatch() * 애플리케이션 상태를 변경하기 위해서는 리듀서 함수인 login(), logout()을 호출하거나 변경된 상태를 전달(notify-통지) 받아야만 하는데 이를 위해서 useSelector(), useDispatch() 를 활용한다. * useSelector() 는 컴포넌트 내에서 애플리케이션 상태를 받아서 자신이 원하는 상태 데이터를 선별(select)하는 용도로 사용한다. 예를 들어 로그인 상태가 변경되는 것을 알아야 하는 컴포넌트는 useSelector() 를 이용하게 된다. * useDispatch() 는 리듀서를 통해서 만들어진 새로운 애플리케이션 상태를 반영하기 위해서 사용한다. 예를 들어 로그인 페이지에서 로그인이 처리되면 useDi..

* 컴포넌트로 개발할 때 가장 주의를 기울여야 하는 설계는 컴포넌트들의 전체적인 구조와 컴포넌트 간의 통신이라고 할 수 있다. 리액트의 컴포넌트는 고유한 상태를 유지할 수 있지만, 여러 컴포넌트 사이에서 발생하는 공유가 필요한 상태 데이터를 관리하기 위해서는 Context나 Redux(이하, 리덕스) 등을 활용한다. * 리덕스를 활용한 상태 관리는 개발을 좀 더 쉽게 할 수 있는 리덕스 툴킷(Redux toolkit)이라는 라이브러리를 활용할 수 있는데 예제에서는 이를 이용해서 사용자의 로그인 상태를 처리하고 JWT를 사용하는 API 서버의 접근 방식에 관해서 알아본다. * 이번 장의 개발 목표는 다음과 같다. 1. 리덕스 툴킷 설정 2. 컴포넌트 간의 상태 공유 3. 비동기 처리와 리덕스 툴킷 4. 쿠..

5. Refresh Token* Access Token은 일반적으로 짧은 유효시간을 지정해서 탈취당하더라도 위험을 줄일 수 있도록 구성한다. 그 때문에 일반적으로 Access Token이 만료되면 사용자는 Refresh Token을 활용해서 새로운 Access Token을 발급받을 수 있는 기능을 같이 사용하는 경우가 많다. * 프로젝트에서는 /api/member/refresh 라는 경로를 통해서 Access Token 과 Refrech Token 을 검증하고 Access Token이 만료되었고, Refresh Token이 만료되지 않았다면 새로운 Access Token을 전송해 주는 기능을 구현한다. * 구현하려는 기능은 다음과 같은 조건들을 만족시켜야 한다.- Access Token 이 없거나 잘못된..

4. Access Token 체크 필터 * Access Token 은 말 그대로 API 서버의 특정한 경로를 '접근'하기 위해서 사용한다. Access Token은 HTTP 헤더 항목 중에서 Authorization 항목의 값으로 전달해서 서버에서 이를 체크해서 사용한다. Authorization 헤더는 , 의 형식으로 중간에 공백 문자로 구분된 값으로 구성되는데 일반적으로 JWT를 활용하면 Bearer 라는 타입으로 지정된다. * 서버에서는 보호하고자 하는 자원에 대해서 Access Token을 체크해서 유효한 경우에 접근을 허용하는 구현이 필요한데 필터나 스프링 MVC의 인터셉터, 스프링 시큐리티의 필터를 활용해서 구현할 수 있다. 예제에서는 시큐리티를 이용하고 있으므로 필터를 추가해서 /api/to..

3. JWT 문자열 생성 * API 서버는 API 호출에 대해서 상태를 유지하지도 않고, 세션이나 쿠키를 사용할 수도 없기 때문에 API 호출 시에 인증된 사용자를 확인하는 방법으로 JWT(JSON Web Token) 문자열과 같은 문자열 토큰 기반의 인증 방식을 사용한다. * JWT는 '헤더 + 페이로드 + 서명'으로 구성된 문자열이지만 서명과 유효시간을 지정할 수 있기 때문에 이를 이용해서 사용자의 인증 정보를 활용하는 경우가 많다. API 서버는 사용자의 상태를 유지하지 않기 때문에 JWT와 같은 토큰을 매번 같이 전송해서 인증을 확인하는데 이러한 용도로 사용하는 토큰을 흔히 Access Token이라고 한다(Access Token을 JWT로 만들어야 한다는 규칙은 없지만, 여러 장점 이 있어서 많..