내가 보려고 만듬

발단 웹페이지를 구축하면서 분명 잘 실행되던 웹페이지가 api 요청을 보내면 바로 405를 반환하는 문제가 생겼다. 구글링해보면 대충 서버에서 인지하고 있는 요청이 아니라는 뜻으로 보인다. nginx나 다른 세팅을 봐도 문제는 없는데, 그리고 문제가 있을거면 애초에 정적파일도 보여지면 안될텐데 왜 api요청에서 문제가 생길까? 해결 과정 결국 405가 나오는 근본적인 원인은 서버에서 원하지 않는 요청이 들어와서 뱉어냈다는건데, 포스트맨에서 테스트하고 바로 깨달았다. 스웨거에서 테스트할땐 알아서 세팅된 Url을 반환해주니 이해하지 못했는데, api서버로 요청을 보낼때 api로 시작하는 엔드포인트로 보내야 하는데 그렇지 않고 스샷과 같이 auth/login 으로 보내고 있는 것을 확인할 수 있었다. 그렇다면..

구현하게 된 계기, 기획은 아래 링크에서 확인할 수 있다. https://prpn97.tistory.com/123 [세션 / 토큰 로그인 프로젝트] 고도화(2) 멱등성 검사 미들웨어(1) 계기 및 기획 계기 기본적으로 get, put, delete는 멱등하고, 멱등하지 않은 메서드는 post, patch로 알고 있다. 동일한 요청을 여러 번 반복했을 때 결과값이 동일하면 멱등한 것이라고 볼 수 있는데, 단순하게 로그 prpn97.tistory.com 구현 과정 앞서 설명했듯, 클라이언트의 요청이 들어오는 시점에서 가장 먼저 해당 미들웨어를 두고 로직이 작동하기 전에 로그를 기록하고, 작동한 후를 직전 로그와 비교하는 방법으로 구현하였다. 1. saveRequestToDB 요청시점의 로그를 기록하는 미들웨..

계기 기본적으로 get, put, delete는 멱등하고, 멱등하지 않은 메서드는 post, patch로 알고 있다. 동일한 요청을 여러 번 반복했을 때 결과값이 동일하면 멱등한 것이라고 볼 수 있는데, 단순하게 로그인은 계속 요청을 보내도 똑같이 로그인이 될텐데, 왜 멱등하지 않은가?를 생각했다. 아니, 로그인을 왜 post로 처리하지? 라고 먼저 생각을 했다. 생각해보면 db의 값을 조회하니까 get 아닌가? 정리하면 이렇다. 로그인을 get으로 보낼 수도 있지만, get으로 보내게 되면 보안 상 여러 이슈들이 생길 수 있다. 원초적으로 앞서 언급한 것처럼 db에서 계정을 조회해서 로그인여부를 확인할 수 있고, 그렇게 해야 하지만 지금 내가 공부하는 것처럼 세션이나 토큰을 통하지 않고 직접 아이디와 ..