[세션 / 토큰 로그인 프로젝트] 고도화(2) 멱등성 검사 미들웨어(1) 계기 및 기획

계기

 

기본적으로 get, put, delete는 멱등하고, 멱등하지 않은 메서드는 post, patch로 알고 있다.

동일한 요청을 여러 번 반복했을 때 결과값이 동일하면 멱등한 것이라고 볼 수 있는데,

단순하게 로그인은 계속 요청을 보내도 똑같이 로그인이 될텐데, 왜 멱등하지 않은가?를 생각했다.

아니, 로그인을 왜 post로 처리하지? 라고 먼저 생각을 했다. 

생각해보면 db의 값을 조회하니까 get 아닌가? 

 

정리하면 이렇다.

로그인을 get으로 보낼 수도 있지만, get으로 보내게 되면 보안 상 여러 이슈들이 생길 수 있다.

원초적으로 앞서 언급한 것처럼 db에서 계정을 조회해서 로그인여부를 확인할 수 있고,

그렇게 해야 하지만 지금 내가 공부하는 것처럼 세션이나 토큰을 통하지 않고

직접 아이디와 패스워드를 클라이언트와 서버가 주고받는 것은 보안상 너무 위험하다. 

 

로그인을 요청할 때마다 눈으로 보이는 결과는 로그인된 상태로 그칠지 모르지만, 

요청할 때마다 세션이나 토큰을 발급하기 때문에 뒤에서는 다른 결과를 초래한다. 

그렇기 때문에 post로 보내야 한다. 

 

 

이러한 경우처럼, 멱등성에 대해 처음 공부할 때는 무작정 메서드를 기준삼아 구분했지만

상황에 따라 메서드가 멱등하게 / 멱등하지 않게 구현할 수도 있다는 것을 알았다. 

그래서 어떤 요청인지에 따라 메서드를 구분하기 전에 메서드가 어떤지와 상관없이

api 요청 전과 후를 비교해서 달라지는지 구분하는 미들웨어를 만들어보려 한다. 

 

 

기획

 

어떻게 구현할지에 대해 여러 고민하고, 실제로 테스트했다. 

모든 요청이 들어올 때마다 객체에 아래의 값을 저장했다. 

get도 그렇고 멱등한 메서드는 제외할까 고민도 했지만,

메서드를 구분은 하되, post도 멱등할 수 있고, get이 멱등하지 않을 수 있기 때문에

(그렇게 구현하면 안되기 때문에) 다 확인하기로 했다. 

    const requestData = {
      method: req.method,
      url: req.url,
      body: JSON.stringify(exceptPassword) || null,
      cookie: JSON.stringify(req.cookies) || null,
      key: key,
    };

결국 요청하는 시점의 전후를 비교해서 변동사항의 유무를 체크해야 한다. 

 

라우터가 작동하기 전에 requestData를 저장하고, 

라우터가 작동하고난 뒤 requestData를 불러와서

previousData와 currentData로 구분하여 비교하면 될 것 같다. 

 

다음 포스팅을 통해 구현하는 과정에 대해 기록하겠다.