22. 9.25(1주차 회고)

배운 내용 및 트러블 슈팅은 TIL을 참고해주시길 바립니다.

1, 미니 프로젝트 (1~4일차)

1. 팀편성부터 시작까지 정신없이 진행되었다. 만난 팀원들과 바로 팀 아이디어 발제를 했고 SA 작성에 구글 스프레드 시트 작성까지 말 그대로 시작부터 폭풍이었다.

2. 프로젝트 구성이 끝나고 바로 깃허브에 세팅을 마치고(다행히 내가 깃을 할 줄 알아서 다른 팀들에 비해 빨리 시작할 수 있었다.) 프로젝트를 시작했다. HTML의 기본적인 것부터 내가 맡았던 게시판 CSS 구성까지. 오랜만에 다시 만지는 div 태그 손보기가 생각보다 쉽지 않았다.

3. 게시판 기능에서 막히는 부분들이 어찌 저찌 팀원 간의 소통이 잘 되어서 마무리가 되었다. 다른 팀원들에 비해서 금방 프로젝트 내용을 마칠 수 있었고 덕분에 강의 들을 시간이 좀 생겨 꾸준히 강의를 들었다. 중간 중간 팀원이 막히는 부분을 함께 고민하긴 했지만 일단 개념 잡는데에 중점을 두기로 했다. 물론 잘 잡히진 않았지만..

4. 그렇게 밤을 거의 새가며(첫날 1시, 둘째날 2시, 셋째날 3시...) 프로젝트가 배포까지 완료되었다. 다행히 잘 돌아갔고 팀장님의 멋진 발표로 빛을 봤다. 그렇게 뿌듯한 마음으로 4일차를 마무리하고 푹 쉰 것 같다.

2. 팀 알고리즘

1. 그러고 다음날 지각을 했다. 너무 맘을 놓은 탓인걸까..

2. 그래도 새로운 팀원분들과 소통하며 알고리즘을 엸심히 풀고 있다. 지금은 기본 마라톤 부분까지 다 풀고 (2일 걸림) 개념정리까지 다 해놓은 상태. 이제 꾸준히 복습하며 새로운 것을 풀어볼까 고민중이다. 일단 체력 충전을 위해 쉬기로 한다. 하루 쯤은 쉬는 것이 맞다고 판단해서다.

물론 프로젝트가면 안 그러겠지..

알고리즘 나름대로 재밌었다. 풀리면 물론 재밌고 아니면 짜증은 나지만 그래도 하루 하루 성장하는 느낌을 받아 좋다. 파이썬으로 작업을 해본 경험이 여기서 빛을 발한 것 같다. 검색 실력도 많이 늘었고 말이다. 공식문서 보는 습관도 챙겨가고 있다.

3. JWT

참고링크

0. 등장 배경

• 세션과 쿠키를 이용하여 인가하는 과정에서 여러 서버가 생겨나면서 발생한 문제에서 나옴.(세션은 한 서버에서만 활동하는데 서버가 여러 개가 나온다면..?!)

1. 특징 : 자가 수용적(Self-Contained)

무슨말인가하면, 필요한 모든 정보를 자체적으로 지니고 있다는 뜻.

-토큰의 기본 정보, 전달할 정보(e.g. 유저 정보), 토큰이 검증되었다는 증명인 signature

그래서 쉽게 전달 될 수 있다.

e.g HTTP 헤더에 넣어서도, URL 파라미터로도 전달 할 수 있다.

2. 언제 쓸까? : 주로 회원인증에 쓰이지만 정보 교류에도 쓰인다.

회원 로그인 상황

유저 로그인 -> 서버가 토큰 발급하여 유저에게 전달 -> 클라이언트 요청 받을 때마다 토큰 유효성 서버가 검증

그렇다면 토큰은 어디에 저장되는가??

클라이언트가 토큰을 받으면 이를

1. 웹스토리지, 혹은 세션 스토리지에 넣고 요청할 때마다 HTTP 헤더 값에 넣어서 요청한다. -> XSS 해킹 공격에 노출된다.(악성스크립트 노출)
2. 쿠키에 넣는다.(전송수단) -> 쿠키에 한정된 도메인에서만 사용된다는 점과 CSRF 공격(사이트 외부에서 사이트 API를 사용하는 것처럼 모방하는 것)

3. 생김새

1. Header

• typ : 토큰의 타입, JWT
• alg : 해싱 알고리즘 지정, SHA256, RSA...

2. Payload : 토큰에 담을 정보가 들어있다.

정보의 조각 : claim(name / value 쌍) -> 등록된, 공개, 비공개 클레임으로 나눔

• 등록된 클레임 : 서비스에 필요한 것이 아닌 토큰에 대한 정보를 담기 위해 이름이 이미 정해진 클레임들(토큰 관련 내용들)

• 공개 클레임 : 충돌이 방지된 이름을 가지고 있다. URI 형식으로 짓는다

• 비공개 클레임 : 등록도 공개도 아닌 클레임들. 클라이언트 - 서버 협의하 사용되는 클레임 이름들(이름이 중복되어 충돌이 일어날 수 있다)

3. Signature : 헤더, 페이로드의 인코딩값을 합한 후 비밀키로 해쉬해서 생성

4. API

참고 블로그

1. api란?

• Aplication Programming Interface, 응용프로그래밍인터페이스
• 응용 프로그램에서 사용할 수 있도록 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. - 위키백과 참고

그래서 뭔데? : 마치 은행 창구와 같다. 우리가 하는 프로그램에서의 모든 장치를 api라 생각하면 조금 편하다. (단추를 눌렀을 때 뭐가 뜨는 것, 결제를 위해서 뭔가를 켜는 것 등...)

2. 인증키가 있다.

• 왜냐면 데이터베이스를 아무나 갖다 쓰면 안 되니까.

3. Open API

• 외부 사이트와 자유롭게 활용 및 공유되도록 설계. 유튜브, 네이버, 카카오 등에서 오픈소스로 제공하고 있음. 물론 무료지만 호출수에 따라 비용이 발생할 수 있음.

• e.g. 지도 api 등...

  결론 : api를 만든다는 건 어떤 서비스의 조각을 만든다는 뜻 같다. 이번주에 만든 내 기능들이 하나 하나 다 api였다는 것을 이번에 알았다.

일단 이번주는 이렇게 마무리 해야겠다. 다음주의 나는 더 성장했음 좋겠다.