내가 보려고 만듬

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

문제 같은 라우터에서 api를 실행했다. 어떤 api에서는 req.cookies의 값이 정상적으로 확인되는데, 특정 api에서만 req.cookies 값이 null로 확인되었다. 마찬가지로 세션데이터 등 여러 req에 관한 값이 확인되지 않았지만, req 자체는 정상적으로 확인되었다. 납득이 되질 않았다. 미들웨어 자체의 순서나 다른 부분의 문제일 수가 없는게, 같은 라우터 안에서 컨트롤러만 다른 상황이라 동일한 순서 안에서 실행되는 것이기 때문이다. 세션을 검사하는 api에서는 쿠키가 보이는데, 세션을 연장하는 api에서는 쿠키가 보이질 않았다. 해결 과정 두 api의 차이점은 메서드였다. 세션을 검사하는 api는 get, 세션을 연장하는 api는 put이였다. 세션 검사는 조회하는 것이기 때문에 ge..

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

cs에 대해 처음 공부하면서, 가장 많이 접한 것들 중 하나는 배열이다. array를 정의해보면 다음과 같다. Array 가장 기본적인 자료구조로, 논리적 저장 순서와 물리적 저장 순서가 일치한다. 그렇기 때문에 index로 해당 element에 접근할 수 있다. 찾고자 하는 element의 index를 알고 있으면 Big-O(1)에 해당 원소로 접근할 수 있다. array에서 맨 앞이나 맨 끝이 아닌 중간에 원소를 삽입, 혹은 삭제하는 과정을 생각해보자. 원초적인 방법은 자리를 만들어서 더하는 과정이다. 1. 해당 원소에 접근하여 O(1)로 작업 완료, 2. 더하거나 빼는 작업O(n)으로 구분된다. 접근하는 과정이 필요한 이유는, index를 알아야 하기 때문에 삽입할 자리를 만들기 위해서 기존 ind..

면접준비를 하면서 TDD에 대해서 공부하게 되었다. 테스트코드, 이름만 들었을 때 만든 코드를 테스트하는 것인가? 라는 생각이 들었다. 누군가는 테스트코드를 무조건 필수라고 말하기도 하고, 누군가는 굳이? 라는 말을 하기도 한다. 역시 직접 공부하며 구현해보기 전에는 왜 쓰는지 그 이유를 정확하게 알기가 어려운 것 같다. 어떤 것인지 공부하며 뜯어보자. TDD 란 ? 일반적으로 테스트코드라고 불리우는 이것은 Test-Driven Development(TDD)라고 하며, 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스이다. 우선 개발자는 요구되는 새로운 기능에 대한 자동화된 테스트케이스를 작성하고 해당 테스트를 통과하는 가장 간단한 코드를 작성한다. 일단 테스트 통과하는 코드를 작성하고 ..

목표 쿠키에는 세션id가 들어있고, 세션id를 만료시켜서 쿠키가 실제로 유효하지 않도록 할 것이다. 의도 지난 포스팅에서도 문제를 제기했듯, 세션Id를 쿠키에 담아서 전송하게 되면, 그대로 세션Id가 노출이 되기 때문에 세션id를 db에서 관리하는게 의미가 없지 않나 싶다. 세션로그인의 장점은 인증정보를 클라이언트가 아닌 서버에서 관리한다는 것인데, 쿠키로 주고받는다는건 클라이언트 또한 세션id를 알고 있기 때문에 언제든지 세션하이재킹에 노출될 위험이 있기 때문이다. 다만, 클라이언트의 직접적인 접근을 막기 위해 httpOnly와 https로의 접근만 허용하도록 secure을 설정할 수는 있겠지만, 그 이외에 내가 로직으로 구현해서 신경쓸 수 있는 부분이 어떤 부분일지 고민해보았다. express-ses..

기획 의도 순전히 나에게 필요해서 만들어보게 되었다. 내가 페르소나다.. ㅎㅎ 광고, 알림, 혹은 검색 등을 통해 필요한 상품들의 특가정보를 알 수 있지만 해당 상품이 정말로 가격이 합리적인지, 혹은 같은 상품군의 다른 상품은 얼마인지 등을 알기가 어려웠다. 물론 상품마다 특수성은 있을 수 있지만, 그런 상품은 애초에 적당히 비교하고 사겠지만 예를 들어 음식의 경우, 오랫동안 금액을 비교해온 사람이라면 가격과 용량만 봐도 어느정도 평균적인 가격이 바로 계산이 된다. ex) 계란 한 판이 이 가격? 비싸다. 만두 1kg가 이 가격? 괜찮긴 한데 더 싼게 있을 것 같은데? 라는 생각들을 하게 된다. 직접 여러 사이트를 비교해야 하고, 용량 단위가 다르다보니 가격을 계산해야 하고, 완벽하게 세상의 모든 상품을..

계기 세션로그인의 장점을 생각해보면, 사용자의 인증정보인 세션ID를 클라이언트가 아닌 서버에서 보관하기 때문에 비교적 인증정보를 탈취당할 위험이 줄어든다는 것인데, 세션로그인을 구현하면서 한 가지 의문이 있었다. 결국 클라이언트와 서버가 인증정보를 주고받으며 해당 사용자임을 입증하는데, 서버는 세션 데이터를 db에 보관하지만 그 값을 쿠키에 담아서 클라이언트에 보내준다면.. 아무리 httpOnly, secure 등 쿠키에 여러 설정을 한다고 해도 당장 개발자도구만 열어봐도 쿠키에 세션id를 넣어서 주고받기 때문에 세션하이재킹을 피할 수가 없다고 생각했다. express-session의 설정 중 secret으로 긴 문자열을 환경변수에 저장하여 쓰지만, 복호화를 하든지 말든지 그 값 그대로 데이터를 주고받..

진행 상황 현재까지 구현한 바는 다음과 같다. 1. 세션 로그인, 토큰 로그인 개별로 로그인 2. res.cookie로 각각 sessionID, tokenID를 담아서 전송 3. 세션로그인을 하면 express-session으로 설정한 session의 session_id, data, expires를 mysql db로 전송 4. sessionData 그대로 전송하여 로그인 오른쪽에 노출, 직접 비교하기 위함. 5-1. 쿠키의 expires, maxAge를 각각 다르게 설정함. 아래에서 비교 확인가능 5-2. 토큰에는 쿠키의 maxAge를 60000으로 주어 1시간으로 설정, 세션은 쿠키의 만료기간을 설정하지 않아서 Session으로 확인됨 (로그아웃하지 않으면 새로고침하거나 브라우저 다시 접속해도 로그인상..

중간점검 중간점검이라고 해도 세션로그인을 구현해놓고 토큰로그인은 ui만 만들어진 상태긴 하지만 그 전에 mvc 설계를 생각해보며 1차적인 리팩토링을 진행했다. 엘리스에서 진행했던 2차 팀프로젝트에서 시퀀스다이어그램을 만들어보긴 했지만 아직은 익숙하지 않아서 이번 프로젝트까지는 전반적으로 다 구현한 후 돌아보는 형식으로 시퀀스다이어그램을 만들 예정인데, 그렇다보니 맨 처음엔 index.js에 모든걸 넣었다가 내가 코딩하는게 불편해서 라우터를 나누었다. 구현하는 자체가 너무 재밌어서 정리보다 만들고 싶은 마음이 앞서서 세션로그인을 마무리하고, 그 후로 정리를 미뤘는데, 이제 그 시간인 것 같다. mvc 설계 ...? 모델(Model): 데이터와 비즈니스 로직을 담당하며, 데이터베이스와 상호작용하고 데이터를 ..