http 강의

proxyman charles, Fiddler 등을 사용

데이터를 주고받고 동기화 서버클라이언트 구조의 장점

• 중앙 집중 관리
  • 모든 데이터 관리를 서버에서 관리
• 장치간 통합성

단점

• 서버 의존성
• 보안 취약성
• 데이터 불일치
  • 네트워크 지연이나 오류가 발생했을 떄 서로가 가지는 데이터가 다를 수 있음

클라이언트 보안이 좋아도 서버가 털리면 다 털림 메서드를 보고 이에 대한 행동을 추측을 할 수 있어야 함. 약속이지만 꼭 지키자.

status code

• 200 ok
• 301, 302, 307=302, 308=301 페이지 이동, 리다이렉트,
  • 301 영구적 이동, 앞으로 계속 다른 곳으로 보내
    • 301과 함께 location: b.com → 바로 b.com으로 클라이언트 요청을 보냄. 근데 301의 경우 이 플로우가 지나면 클라이언트가 내부적으로 다시 요청을 보내야 하는 경우에 앱 삭제후 재설치할때까지 b.com으로 보내게 됨.
  • 302 found, moved temporaly 임시적 이동
    • 앱을 껐다 키면 다시 a.com으로 보내게 됨.
  • 301은 절대 쓰지 말고 302만 쓰기 약속보다는 빡센 표준. 지키지 않았을 때 오동작하는 경우도 있음

게시판 서비스에 글을 작성하는 API 서비스 제약 조건

• 글의 최소 글자수
• 이모지 사용불가
• 태그 최소 입력 등.. 실패할 경우 대부분 → 여기서 400번대 찾아 씀
• 499 제목 최소글자
• 498 본문 이모지 있는 경우,,
• 497 ~… 이렇게 할 수는 있는데 이렇게 하면 만들 수 있는 에러의 종류가 99개밖에 안됨. 서비스의 제약사항이지 오류가 아니다.

로그인에서도 아이디 패스워드 틀린 경우에는 200으로 처리

• 401 → 로그인되지 않은 상태에서 다른 인증이 필요한 요청을 할 떄

map local → 서버로부터 내려오는 응답을 가로챌 수 있음 proxyman은 쿼리를 인지하지 못함

네트워크 지연 → Network Conditions

• 어떤 Host로 가는지

중간자공격 중간에 들어가서 요청 조작하기 네이버 웹툰을 보고 조작 이 툴을 잘 사용하면 생산성을 높일 수 있지만 잘못 사용하면 해커 SSL pinning 프록시를 보면 CONNECT 단계에서 에러가 뜨면 SSL Pinning의 적용 SSL 중간에 프록시가 끼게 되면 프록시를 설치할 때 사설인증서를 추가하고 신뢰설정을 하면 중간에 인증서가 바뀜 SSL Pinning → 서버에 SSL 인증서를 둘 것임(A) 클라이언트에서는 클라이언트를 배포할 떄 A에 대한 정보를 넣음. 그럼 중간에 프록시가 끼게 되면 B라는 인증서로 B라는 SSL 인증서가 오고, 클라이언트는 이에 대해 오류를 띄우게 함. 앱을 배포했을 때 앱의 생성 주기는 인증서의 유효기간과 같다.

API 키를 여러개 해놓음 어떤게 limit 초과로 장애가 나면 새롭게 추가 노출이 가능한 키와 아닌 키 구하기