지난 강의에서는 지금까지 배운 큰 과정을 복습하고 깊이있게 다루어야 할 개념들을 가르쳤습니다.
댓글
로그인이란 무엇입니까?
– 시스템에 대한 사용자 액세스 또는 수행된 작업을 제어하고 기록하는 컴퓨터 보안 프로그램.
사용자는 누구입니까? “인증”으로 시작합니다.
(본인 확인 절차)
우리는 토큰 방식 로그인 및 세션 방식 로그인 방법을 배웠습니다.
- Token 방식 : Access Token이 유효한지 확인 후, 유효하지 않을 경우 신규 토큰 발급(Refresh Token 사용), 유효하지 않을 경우 토큰 검증
- 세션 방식: 토큰과 동일하나 프런트엔드에서 추가 작업 없음(단순)
세션이란 무엇입니까?
– 사용자 로그인과 로그아웃 사이의 시간입니다.
(세션이 만료되었다고 생각하십시오.)
위에서 자신을 식별한 경우 제어 권한해야 한다.
필요한 경우 자체 리소스에만 액세스하도록 설정해야 합니다.
-> 연습한 userProfile api에서 403 오류가 발생했습니다.
백엔드는 이미 관련 사용자만 필터링하고 전송하지만 프런트엔드에서도 필터링해야 합니다.
- 이전 연습에서는 백엔드에서 직접 차단했기 때문에 403을 제공했지만 프런트엔드에서도 수행할 수 있습니다.
- 프런트엔드에서 유효성을 검사할 수 있다고 해서 백엔드에서 유효성을 검사할 필요가 없는 것은 아닙니다.
서버 검증은 필수입니다.
- 서버 인증 없이 Postman과 같은 도구로 API를 해킹하면 모든 중요한 정보를 검색할 수 있기 때문입니다.
(서버와 프런트엔드 모두에 필터가 필요함)
그럼 서버는 어떤 일(액션)을 할까요?
- 자체 리소스에 대한 액세스 제한(필요한 경우)
- 카카오톡, 인스타그램 등 사용자 ID를 기반으로 다른 사용자 데이터를 볼 수 있는 서비스
- 권한에 따라 동작 제어, 예) Github 저장소의 설정 버튼
위의 두 작업은 서버에서 실행되며, 포그라운드는 권한 제어 작업을 시작합니다.
(결국 양 당사자의 검증 작업은 아직 진행 중입니다)
새로 고침 토큰?
– Refresh Token은 Access Token 재발급 용도로만 사용됩니다.
Refresh Token Rotation -> Token Rotation Policy (완벽한 보안 정책은 아닙니다.
액세스 토큰이 죽었을 때 쿠키가 여전히 존재하지만 CSRF 공격이 들어오거나 도용되어 살아있는 동안 사용되는 경우 답이 없습니다)
Q. Access Token의 Payloda가 변경되거나 특정 값이 변경되면 클라이언트에서 사용하는 모든 Access Token을 새것으로 교체해야 하는데 어떻게 처리해야 하나요? -> 개인 키를 변경합니다.
OAuth: 공개 승인
– 다른 인증 서비스를 통해 기존 서비스(예: Google)에 대한 권한 “위임”
* 배민(개인서비스, 마이서비스), 구글(원본서비스)을 말합니다.
- 기존(기존) 서비스에서 로그인 -> 내 서비스에서 사용 가능하도록 설정(프록시 인증)
- 라이센스를 얻는다는 것은 키를 얻는다는 것을 의미합니다.
Baemin(내 서비스)이 Google(본 서비스)에 등록되면 해당 서비스의 키가 자동으로 생성됩니다. - 사용자의 임시 값은 로그인마다 다릅니다.
- 배민은 구글 로그인을 이용하며, 배민은 사용자 인증 정보 교환만으로 업무를 진행합니다.
그렇다면 이전 OAuth에서는 무엇을 했습니까? 유일한 지루한 작업은 링크를 보내는 것입니다.
open api를 사용할 때와 비슷합니다.
권한에 따라 OAuth 원본 서버(Google)에서 사용자 정보를 가져와서 사용하거나 권한을 위임(예: 캘린더 서비스인 Calendly)하여 인증 자체만 사용할 수 있습니다.
참고: 싱글톤 패턴
– 데이터 소스를 하나로 결합하는 것을 의미합니다.
- 원래 Java와 같은 OOP(Object Oriented Programming)에서 사용되었습니다.
- 한 종류의 데이터를 구분하여 다양한 용도로 사용합니다.
- Redux 스토어의 핵심 개념은 비슷합니다.
- 실습 예제에서는 router.tsx가 예제입니다.
- 프론트엔드에 디자인 패턴을 적용하기는 어렵지만 개념만 알면 비슷하게 구현해서 사용할 수 있습니다.
앞에 싱글톤 패턴이 필요한 이유는 무엇입니까?
- 데이터 소스가 변경되면 유지 관리가 매우 어려워집니다.
API 호출이 겹치더라도 열립니다. - 서비스가 클수록 중요합니다.
결국 핵심은 데이터가 컨텍스트에서 관리되는지 여부입니다.
와는 별개로 모듈 번들러, 폴더 구조개인적으로 vite에 관심이 많은 편이라 이 부분에 대해 좀 더 이야기해줬으면 좋겠는데 주제넘고 수업시간이 많지 않아서 직접 해봐야 할 것 같다.
위로. 2023년 3월 20일 현재 React Beta 문서가 확정되었으며 그 과정에서 권장 CRA가 생략되었습니다.
해외 프론트엔드 개발자들 사이에서 역시 vite가 정답!
CRA가 사라지고 vite가 되어야 한다는 사실을 언급했지만, 나누어진 것 같은데, CRA에 완벽하게 대처하는 웹팩 대체품은 아닙니다.
물론 vite는 속도가 빠릅니다.
Vite 내부를 보면 나쁜 코드와 같은 멋진 댓글이 있지만 이런 것들을 알아낼 만큼 숙련되지 않았기 때문에 혼란스럽습니다.
vite가 webpack보다 설정하기 쉽다는 것은 알지만 배경 지식 없이 사용하면 호환성 문제나 버그가 생길까봐 걱정됩니다.
그래도 사용해보니 괜찮았으니 이번 기회에 모듈번들러를 알아봐야겠네요.
이 실습의 주제: 사용자 권한에 따라 액세스를 제어하는 웹사이트 만들기
4일차 요약
이 수업은 실전 수업이라 시간이 빨리 지나갑니다.
3차, 4차에서는 서버측도 복제해서 실행했는데 설정 과정에서 많은 분들이 막혔습니다.
좀 당황스럽긴 한데 서버쪽은 전혀 모르고 사전할당시 서버를 로컬로 설정해서 작업을 했기 때문에 별 어려움 없이 할 수 있었습니다.
이번에 가장 큰 느낌은 TS를 사용하게 된 것이 행운이라는 것입니다.
물론 더 큰 프로젝트를 진행하고 있다면 간단한 로직으로 더 광범위한 코드를 작성해야 하겠지만 나중에 발생하는 오류를 확인할 수 있다는 점이 매력적으로 보입니다.
그리고 스스로의 한계를 미리 설정하고 “이건 어렵다.
프론트 데스크가 아직 이 정도는 알 필요가 없다”고 말하는 안주와 두려움이 내 성장의 걸림돌임을 깨달았다.
나는 늘 스스로를 느린 사람이라고 과소평가해왔지만, 그것은 어려움을 마주하기 싫어서 회피하는 행동일 뿐이었다.
이렇게 하면 어떻게 되나요? 그래도 꾸준히 하고, 좋은 코드 많이 접하고, 자신감 있게 작업하는 게 필요한 것 같아요.