Week1 회고

이태성·2022년 3월 16일
0

항해99

목록 보기
1/9

서론

이번 포스팅은 항해99 과정 중 무려 1주차가 끝이 나게 되어 한주동안 배운것을 정리겸 회고록을 작성해 보기로 하였다. 1주차에는 아래것들을 배웠다.

  • 해시함수를 활용하여 회원가입기능을 구현
  • JWT(Json Web Token)을 활용하여 로그인 기능을 구현
  • API을 활용한 GET요청으로 데이터 받아오기

본론

  • 회원가입기능
    회원가입기능을 구현하는 방법에대해서 말하자면 우리가 회원가입시 가장 중요한 2가지요소가 있다.
    바로 ID와 PW인데, PW의 경우 DB에 그대로 저장이 되면 법적으로나 보안상으로나 문제가 생긴다!! 그래서 암호화를 해주어서 DB에 저장을 해주어야한다. (ID는 그냥 저장해도 무관한듯 하다.)
    따라서 PW를 해시함수를 활용해 암호화 해준다. 해시함수는 다음과 같은 특징들이 있다.

    해시함수의 특징

    • Input에 대하여 암호화 후 항상 똑같은 길이의 암호화된 값을 Output으로 뱉어준다.
    • Output으로 Input을 절대 유추할 수 없는 일방통행 함수이다.
    • Input의 털끝하나만 값을 변경해도 완전히 다른 Output이 나오게 된다.
    • 관련 실습 사이트 링크 : https://www.convertstring.com/ko/Hash/SHA256
  • 로그인 기능
    로그인 기능을 구현을 하기위해서는 다음과 같은 사전지식이 필요하다.

    • Q1 : 한번만 로그인하게 되면 어떻게 사이트는 지속적으로 내가 로그인 했다는 것을 체크하는 것일까??
    • A1 : JWT(Json Web Token)라는것을 이용한다. 놀이공원의 입장권한 팔찌 같은것이라고 생각하면되는데, 정의는 JSON형식으로 사용자의 정보를 안정성있게 전달하는 웹표준 방식이다. 사용자와 서버는 JWT를 계속해서 주고 받음으로서 로그인이 되어있다는 상태를 구현하는 것이였다!
    • Q2 : 그렇다면 서버입장에서 사용자에게 어떤 방식으로 JWT를 발급 및 유지해주는 것일까??
    • A2 :
    1. 사용자가 입력한 ID와 PW를 서버가 읽어와서 PW를 해시함수로 암호화를 한다.
    2. DB에서 ID와 암호화된PW를 대조해서 일치하는 유저가 있는지 찾아본다.
    3. DB에서 일치하는 유저가 있다면 2가지를 준비해주는데, payload와 SecretKey이다. 이 2가지를 해쉬함수에 넣고 암호화 해주면 jwt 토큰이 만들어지는것이다.
      3-1. payload에는 사용자의 ID, 토큰만료시간(=로그인 유지가능시간)이 들어간다.
      3-2. SecretKey에는 서버에서 정한 특정 문자열이 들어간다.
      3-3. 잘 만들어진 jwt를 사용자에게 보내준다.
    4. 사용자는 jwt를 쿠키라는 곳에 보관을 해둔다. (쿠키는 브라우져에 있는 DB라고 생각하자.)
    5. 사용자는 사이트내에서 어떤 요청을 보낼때 마다 쿠키에서 jwt를 꺼내서 같이 전송해줌으로서 로그인 상태를 유지하게 된다!!
  • API (Application Programming Interface)
    API는 전에 썼던 포스팅에도 종종 등장하던 개념인데, 쉽게 예시를 들자면 우리가 좋은 레스토랑에 있다고 가정해보자!
    우리는 원하는 메뉴를 골라서 점원에게 주문을 넣고 점원은 주문내용을 요리사에게 전달할 것이다. 그러면 다시 요리는 요리사 >> 점원 >> 여러분의 식탁! 순으로 돌아오게 된다!
    이때 점원=API라고 보면 된다! 요리사와 우리사이에 위치하여 각종 요청을 중개해주는 중간다리 같은 역활인 것이다!
    UI (User Interface)란 기계와 인간 간의 소통창구로서 사용자는 기계에 명령을 넣고 명령의 결과와 정보를 받아오기위한 모니터 혹은 스크린 등이 Interface라고 할 수 있다, 그렇다면 소프트웨어와 소프트웨어간 소통창구는 뭐라고 할까?? 바로 API 다.
    API는 소프트웨어간 지정된 형식으로 요청, 명령을 받을 수 있는 수단을 말한다.

    • REST API
      REST API는 일반적으로 API를 사용한다고 하면 가장 흔하게 접할 수 있는 API형식이다.
      필요한것은 요청을 보내고 싶은 url, 요청하는 데이터의 형식(보통API문서가 같이 배포됨)이다. 사용예시 : 기상청이 제공하는 날씨API를 사용하고 싶다면, 날씨API를 제공하는 url에다가 API문서에 명시된 형식으로 {"지역":서울, "알고싶은거":내일 비오는지} 이런식의 JSON형식으로 요청을 보내면 기상청서버는 서울에 해당하는 내일 날씨를 응답해준다!
      특징으로는 다음과 같은것들이 있다!
      • 단순함 : JSON형식으로 데이터를 주고 받으므로 사용하기가 단순하고 간편하다.
      • 성능과 확장성 : REST API는 구축과 확장이 간단하며 크고 복잡하게 확장또한 가능하다.
    • SOAP API
      이건 써본적이 없어서 찾아본결과 보안수준이 높아야할때 사용되는 방식으로 REST API에 비하여 사용이 복잡하고 어렵다는 특징이 있다고한다. 데이터 포맷은 XML형식으로만 주고받는다고한다. 그리고 상대적으로 더많은 네트워크 리소스와 대역폭을 필요로 한다고 한다.
      따라서 일반적으로는 많이 사용하지 않게 될거같은 API형식이다!

결론

이번주차에는 솔직히 가장 궁금했던 회원가입과 로그인 기능을 직접 구현해보면서 경험하는 주차로서 가장 중요한것을 배웠다는 느낌이 들었다. 토큰과 쿠키로 로그인 기능을 유지해 주는 부분이 상당히 나에겐 재밌게 다가왔다. 아마 여기서 좀더 보안을 강화시키거나 하려면 기본틀은 비슷하고 디테일이 좀더 붙어서 보안을 강화시키는 것으로 예상된다. 또한 API문서 또한 이번 주차에 여러번 읽는 기회가 생겨서 다음번에 또 다른 해외사이트에서 제공하는 API문서를 보더라도 좀더 빠르게 기능구현을 할 자신이 생겼다!!

profile
재밌게 뚫고 나가자

0개의 댓글