원티드 FE 챌린지 3월 노트 3

2023-03-14
session
세션 방식 로그인을 해 봅시다

세션이란 무엇인가

세션이란 명확하게 실체가 있는 것이 아니므로 세션의 기술적 실체를 알아보자

로그인 : 신원을 증명. 이 때 Token을 사용하게 됨 (Token : 물리적인 데이터 조각)

매번 토큰을 들고 요청을 하게 되는 것이 이론적으로 맞는데, 실제로는 그렇게 하지 않는다.

대화의 Context가 유지되기 때문에 매번 Token을 내밀지 않아도 되는 것.

서비스가 브라우저에 표시를 해 두고. 브라우저에서 요청을 보낼 때 세션 아이디를 보내게 한다.

서버가 유저를 세션 아이디로 식별하게 되는 것 ➡️ 세션 방식 로그인

그래서 세션이란 (사실 명확한 정의는 없음) ➡️ 사용자의 로그인 이후부터 로그아웃 혹은 로그인 만료까지의 기간

세션 방식 로그인이란 사용자 로그인이 유효한 시간동안 서버에 세션 아이디를 저장해 두고 인증에 사용하는 방식

쿠키란 무엇인가

HTTP 쿠키 - HTTP | MDN

서버가 브라우저에 전송하는 작은 데이터 조각

동일한 서버에 요청할 때 쿠키를 들고 요청합니다.

중요한 건 서버가 브라우저에 전송하고, 브라우저는 저장해뒀다가 쓰면 된다.

쿠키가 동작하는 방식

쿠키는 직접 넣어주는 값이 아닌 브라우저의 내장 기능으로만 사용합니다. 우리가 필요한 것은 값을 넣어주기 위한 설정을 해야 하는것

쿠키 관련 정책

  • Samesite : 같은 도메인에서만 저장하고 전송할것인가 ?
    • None : 아무데나 저장하고 전송함. 사랑의 쿠키 나눔
    • Strict : 동일 출처만 신뢰한다.
    • Lax : 대부분 strict로 취급하지만 안전한 요청 (get, …) 에는 CORS를 제공한다.
  • Httponly : 자바스크립트로 쿠키에 접근할 수 없게 한다. 이 설정을 켜 두면 FE에서는 쿠키에 직접 접근할 방법이 없음.
  • Secure : HTTPS만 사용

Strict이나 Lax인 경우에는 중간에 모아주는 작업을 해 줘야 (프록시 서버를 둔다거나) CORS 이슈가 발생하지 않는다.

CORS

Cross-Origin-Resource-Sharing

내 도메인에서 온 게 아닌데 어떻게 신뢰하지?

출처가 다른 요청에 대해 처리하는 정책

실전

실제 서비스가 되기 위해서 더 필요한 것

  • 로그아웃 : 들고 있는 세션을 버린다.
  • 세션 만료, 세션 연장 기능
  • 권한 관리 : 유저마다 접근할 수 있는 정보가 달라야 할 수도 있다. (게시물 수정이라던가..)

세션 vs JWT

  • JWT
    • 서버 / 백엔드 비용이 감소한다.
    • 프론트엔드의 복잡도가 높아진다.
    • 보안상 세션보다 더 위험하다. (Refresh Token Rotation 같은 것들로 보완 가능할지도?)
  • Session
    • 서버 / 백엔드 비용이 대폭 증가한다. (Load Balancer …)
    • 프론트엔드에서의 인증 과정이 간단해진다.
    • 보안이 JWT에 비해서는 좋음 (피싱사이트.. 는 만들 수 있다.)

무엇을 선택해야 하는가

  • 동시접속자 수
  • 서비스 규모
  • 앱/웹 동시에?
  • 팀 내 인력의 구성..
  • …

이런 여러가지 상황을 고려해서 결정해야 합니다.

ETC

이상적인 프로젝트 디렉토리 구조?

(와 진짜 너무 궁금했음 감사합니다!!!!)

근데 이걸 왜 궁금해 했는지를 먼저 생각해 봅시다.

➡️ 내 경우에는 팀원들이 내가 구성한 디렉토리 구조 상에서 파일을 잘 찾지 못하길래.. 였음

근데 강의를 들어보니 국룰은 없고. 협의의 과정이 없었기 때문이 아니었을까… 하는 생각이 들었다… 어쨌든 기능상 문제가 없는 선에서라면 협의 하에 팀원들끼리 잘 알아볼 수 있는 방향으로 구조를 짜서 그걸 국룰로 삼는게 맞다 라는 의견… 인 것 같다. 어찌되었든 프로젝트 디렉토리 구조를 잘 짜기 위한 목적은 생산성을 위함이니까요.

폴더를 나누는 기준을 생각해봅시다. 강사님은 Src 폴더 안에서 (asset 들은 제외합시다! ) 내가 뭘 하려고 하는지를 생각해보는 편이라고 하심.

└── src
    ├── api
    ├── atoms
    ├── component
    ├── hooks
    ├── layout
    ├── pages
    ├── types
    ├── utils
    └── ...

뭐 이런 식으로?

무물보 (를 빙자한 내생각)

전역상태 vs useState : 이 값이 여러 컴포넌트에 사용되는 값인지를 생각해서 결정합니다.

웹팩이란 ? 번들러입니다.

tsx, ts : tsx 파일은 jsx 문법을 사용하는 파일입니다.

asset을 src 아래에 두지 않는 이유 : src 아래에 두면 자바스크립트에 반응하는 ? 객체가 됩니다 ? 하지만 public 아래에 두면 경로에 상관 없이 바로 갖다 쓰게 된다는 장점이 있다… (잘 모르겠다면 webpack 이런 번들러에 대해서 공부해보도록 합시다.) ➡️ public 폴더 안에 넣으면 import 되지 않음. 이게 맞음. 이미지를 이미지 태그로 쓰느냐, 아니면 div 태그로 쓰고 js로 불러오느냐 의 차이인 것 같음… (공부해봐야겠다.)

리덕스를 모르는 채로 리코일만 알고 있어도… 근데 내 생각에는 시간 있으면 공부하는게 맞는 것 같은데 역시 알고 있는게 좋겠다고 말씀하심

에러만 잡다가 아무것도 못하는 신입이 있을까요 ? ➡️ 에러 잡다가 아무것도 못하는 5년차도 있습니다. 사실 내 능력껏 했는데 아무것도 못하는 경우에는 내 탓도 없다고는 할 수는 없지만 PM이 이런저런 전략으로 커버해줘도 됩니다. (신입이면 시니어를 붙여준다거나…) 잘 못해서 진행이 더뎌지는건 상관이 없지만 근데 잘 모르겠으면 바로바로 말을 해야 한다는건 중요합니다… (뭔가 위안이 된다.)

TDD : 프론트에선 별로?

새로운 기술을 공부할 때?

➡️ 아는게 하나도 없다면 그냥 책을 하나 정독하는 것? ➡️ 만약에 아는게 조금 있다면 일단 써보는 것도 좋은 것 같습니다.

컴포넌트 설계 방식 : atomic 하게 하는 곳도 있고 암튼 다양함. 회사 전체에서 공통된 설계 방식은 사용하지 않는 것 같음

TS 짱인거같아여 (절대적으로 내 생각임)

프론트는 유저와의 커뮤니케이션이 중점이 되기 때문에 아무래도 백엔드와는 중점을 두고 있는 개념들이 다를 수 있습니다.

신입 프로젝트

  • 완성도 (는 어느정도 있어야 합니다. (내가 생각해도..))
  • 기획력 (은 사실 신입에겐 별 기대가 없을지도)
  • 많은 기술스택을 경험 (강사님 주관으로는 그렇게 많을 필요는 없을듯)
  • 하지만 너무 얕게 아는건 좀 별로인 것 같습니다. (강사님 주관으로는 오히려 깊게 공부하는 쪽이 좋다고 하심)

주니어 레벨인 경우 주어진 디자인을 CSS로 구현할 수 있는 정보만 충!분!합니다. (ㅜㅜ 블로그 디자인 짜야하는데)

follower의 입장이라면 나의 능력에 대해서 너무 걱정하고 있을 필요는 없다는 것 같다… 내 능력을 판단해서 나를 써준 사람은 leader이기 때문에 일단 자부심을 갖고 있는것도… 좋은 것 같음 (전적으로 내 생각임) 하지만 뭔가 그래도 내가 뭔가 놓치고 있다는 생각이 든다면 leader와 의논해 봅시다.

뭔가 지금 무물보에 전반적으로 둘 중 하나만 공부해야 한다면? 이라는 질문이 많은데 전반적인 답변은 그냥 둘 다임… 솔직히 맞는 것 같음.