📅 DayGrid

'/diary' 경로로 다이어리를 확인하는 도중 다이어리 페이지에서 처음 렌더링은 잘 되다가 새로고침만 하면 404 에러가 발생하였습니다 네트워크 탭에서 확인해 보니, 처음에는 '/diary/id'라는 요청을 잘 보내다가 새로고침만 하면 브라우저가 '/diary/index.bundle.js'라는 경로로 요청을 보내고 있었습니다.

해당 문제는 React Router로 클라이언트 사이드 라우팅을 구현한 웹 애플리케이션에서 발생하는 문제였습니다.
페이지 전환 없이 URL을 변경할 수 있는 브라우저의 히스토리 API를 활용하였으나, 새로고침하면 문제가 발생하였는데
이 문제의 근본 원인은 브라우저가 새로고침할 때마다 서버에 현재 URL에 해당하는 리소스를 요청하기 때문입니다.
만약 '/diary/:id' 같은 서브 경로에서 새로고침을 하면, 브라우저는 해당 서브 경로에 대한 리소스를 서버에 요청하게 됩니다.
그런데 서버에는 그런 경로에 대한 파일이 없어서 404 에러를 반환하게 되는 것이었습니다.
그래서 문제를 해결하기 위해 웹팩의 output.pubdivcPath 옵션을 '/'로 설정하였습니다.
해당 옵션은 빌드한 결과물이 위치할 경로를 지정하는 옵션이며 pubdivcPath를 '/'로 설정하면, 브라우저는 항상 루트 경로를 기준으로 해석하여 루트 경로에서 로드하려고 시도하게 됩니다.
그렇게 된다면 서브 경로에서도 문제 없이 빌드한 결과물을 로드할 수 있게 됩니다.
또한 같은 원리로 웹팩의 devServer 설정에서도 pubdivcPath를 '/'로 설정해야 하며. 항상 루트 경로에서 빌드한 결과물을 제공하게 됩니다.

이 경험을 통해 클라이언트 사이드 라우팅의 동작 방식과 웹팩 설정에 대해서 좀 더 깊은 이해를 하게 되었습니다. 특히, 웹팩의 output.pubdivcPath 옵션과 devServer 설정의 중요성을 체감하였습니다.

프로젝트를 진행하면서 다이어리 작성 시 이미지를 업로드하는 기능이 필요했습니다. 서버 업로드는 서버에게 이미지를 업로드하고 해당 이미지의 URL을 받아와 에디터에 삽입하는 방식으로 정했습니다. 이를 위해 필요한 기능들을 정의하였습니다.

1. 이미지 파일을 선택할 수 있는 UI를 제공.
   
2. 선택한 이미지 파일을 서버에 업로드.
   
3. 업로드된 이미지의 URL을 에디터에 삽입.

이미지 파일을 선택할 수 있는 UI는 에디터로 사용하려던 React Quill안에 있는 image 버튼의 Handler를 이용하였고
선택된 이미지 파일을 서버에 업로드하기 위해 이미지 파일을 적절한 형식으로 변환해야 했습니다. 이를 위해 FormData 객체를 사용하기로 결정했습니다.
마지막으로, 서버에서 받은 응답을 통해 이미지 URL을 에디터에 삽입해야 했습니다. 이 작업을 위해 React Quill의 API를 활용하기로 결정했습니다. 서버로부터 받은 이미지 URL을 에디터의 현재 커서 위치에 삽입하도록 구현하였습니다.
그렇게 이미지 업로드 후에는 자동으로 에디터에 이미지가 삽입되어 사용자가 원하는 위치에 이미지가 포함되도록 할 수 있게 됩니다.

이러한 고민을 바탕으로, 상태관리 라이브러리인 Redux와 커스텀 훅, 그리고 에디터 라이브러리인 Quill을 활용하였습니다.
이를 통해 사용자가 이미지를 선택하면 해당 이미지를 서버에 업로드하고, 업로드된 이미지의 URL을 에디터에 삽입하는 기능을 구현하였습니다.
이 기능을 구현하면서, React Quill 에디터의 확장성, FormData 객체를 이용한 파일 업로드 등 배울 수 있었습니다.

회원제도로 운영하기 위해 로그인을 구현하다보니 프로젝트 초기에는 Access Token과 Refresh Token을 모두 클라이언트의 로컬 스토리지에 저장하고 하는 것으로 생각했습니다.
이 방식은 간단하고 구현이 용이하다는 장점이 있었지만, 보안 문제가 있었습니다.
만약 사용자의 브라우저가 XSS(Cross-Site Scripting)등의 공격을 당하면, 공격자는 로컬 스토리지에 충분히 접근할 수 있고, 이로 인해 토큰이 유출될 위험이 있었습니다.

그래서 위험을 예방하고자 먼저 사용자로부터 입력받은 데이터를 그대로 사용하지 않고, sanitize-html 모듈을 이용해서 살균처리를 한 뒤 HTTPOnly 쿠키를 이용하며 자바스크립트를 통한 접근을 방지하는 식으로 구현하고자 했습니다.
토큰의 보안성을 높이는 동시에 사용성을 유지하는 새로운 저장 방식을 모색하게 되었습니다.
이를 위해, Access Token은 메모리에, Refresh Token은 HttpOnly 쿠키에 저장하기로 결정했습니다.
Access Token은 사용자가 사이트를 이용하는 동안에만 필요하므로, 메모리에 저장하는 것이 적합하다고 판단하였습니다.
반면, Refresh Token은 사용자가 로그인 상태를 유지하기 위해 필요하므로, HttpOnly 쿠키에 저장하는 것이 적절하다고 판단하였습니다.

이렇게 구현한 결과, 토큰 유출 위험을 크게 줄일 수 있었고 사용자의 로그인 상태를 안정적으로 유지할 수 있게 되었습니다.
또한, 이 과정에서 메모리와 HttpOnly 쿠키를 이용한 토큰 관리 방법에 대해 배울 수 있었으며, 이를 통해 웹 보안에 대한 이해도를 높일 수 있었습니다.

회원인증이 필요한 서비스를 이용하기 위해서 API 요청을 보낼 때마다 Access Token을 헤더에 포함시켜 인증을 진행하였습니다.
하지만 Access Token은 보안상의 이유로 만료 시간이 짧게 설정되어 있기 때문에, 사용자가 오랫동안 활동을 하지 않거나, Token이 다른 이유로 만료된 경우 401 에러를 반환하게 됩니다.
그래서 다이어리를 쓰다가 갑자기 로그아웃 되는 등의 문제점이 생기기 시작했고 이러한 문제를 해결하기 위한 방법이 필요하였습니다.

이를 해결하기 위해, Access Token이 만료되었을 때 Refresh Token을 사용하여 새로운 Access Token을 발급받는 방식을 도입하였습니다.
이를 위해 서버에서는 사용자의 Refresh Token을 검증하고, 유효하다면 새로운 Access Token을 발급하는 API를 제공하였고
클라이언트에서는 요청이나 응답을 가로채어 원하는 동작을 수행할 수 있게 해주는 axios의 인터셉터 기능을 이용하여
API 요청 시 401 에러를 받으면, 이 API를 호출하여 새로운 Access Token을 받아와 다시 요청을 보내는 방식을 구현하였습니다.

이렇게 구현한 결과, 사용자는 Access Token이 만료된 경우에도 서비스 이용에 불편함이 없게 되었습니다.
또한, Refresh Token을 사용하여 새로운 Access Token을 발급받는 방식은 보안성과 사용성을 모두 만족시키는 해결책이었습니다.
이 과정에서 axios의 인터셉터 기능 활용법과 토큰 기반 인증 시스템의 동작 원리와 보안 요소에 대해 더 깊게 이해할 수 있었습니다.