내가 보려고 만듬

면접준비를 하면서 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): 데이터와 비즈니스 로직을 담당하며, 데이터베이스와 상호작용하고 데이터를 ..

https://sh5080.github.io/randomImageViewer/ Random Image Viewer sh5080.github.io 부탁을 받게 되어서 기출문제를 문제별로 랜덤하게 넘길 수 있도록 만들어보게 되었다. 기본적인 ui는 gpt에게 맡기고, 로직을 구현했다. 백엔드에 관심이 있어서 지망하고 있긴 하지만, 간단하기도 하고 당연히 할줄 알아야 할 기본적인 간단한 구현이라고 생각해서 시작했는데 시행착오가 있어서 포스팅하게 되었다. 구성 정말 간단하게 디렉토리에 이미지파일을 넣어놓고, 웹에서 버튼을 클릭하면 디렉토리 안에 있는 이미지를 랜덤으로 보여줄 수 있도록 구상을 하고, ui가 만들어진 상태에서 시작했다. 처음 로직을 구현했을 때에는 다음과 같았다. const randomizeBut..

먼저 이번 포스팅에서 다룰 것은 제목과도 같이 어떤 것들을 주고 받는지 살펴보고자 한다. 세팅 내용 이전 포스팅에서 다뤘듯, express-session을 통해 session을 설정하고, session.data 객체를 추가하여 내용들을 담았다. 1. express-session의 설정 //index.js const sessionStore = new MySQLStore({ createDatabaseTable: true, schema: { tableName: 'sessions', columnNames: { session_id: 'session_id', data: 'data', expires: 'expires', }, }, host: DB_HOST, user: DB_USER, password: DB_PASSW..

현재 진행상태 지난 포스팅에서 세션로그인할 때 쿠키에 관련해서 작성했다. 그래서 공부한 것들을 토대로 먼저 내가 구현한 것을 설명하면, 세션검증시 쿠키: 로 되어있는 부분은 req.cookies로, 개발자도구에 보이는 모든 쿠키다. 지금은 1개만 있는 상태다. 이전 포스팅에서 설명했듯, s: 이후 . 까지가 실질적인 sessionID이다. express에서 session을 통해 쿠키를 만들 때 sessionID를 저렇게 넣어준다. 그렇기 때문에 굳이 다른 쿠키를 만들 필요 없이 저기서 파싱해서 쓸 수 있다. 다음과 같이 구현했고, 저렇게 콘솔을 찍어서 위의 스샷대로 확인할 수 있었다. (아직 에러처리 부분은 미들웨어를 만들지 않아서 임시로 저렇게 res로 보내고 있다.) 그렇다면 드디어 sessionID..

이전에 세션 / 토큰 로그인의 과정을 설명했기에 세션 로그인 과정을 간단하게만 설명하고, 본론으로 들어가고자 한다. 세션 로그인에 대해 세션은 비밀번호처럼 인증 정보를 저장하지 않는다. 그 대신 sessionID라는 식별자를 저장한다. 쿠키에 sessionID가 존재하지 않을 경우, 서버에 요청하여 sessionID를 받아 쿠키에 보관한다. 이후 클라이언트가 서버에 요청하면 서버는 sessionID를 key로 가지고 있는 value의 값을 조회, 로그인 여부 혹은 중요 정보를 확인한다. 즉, id와 pw로 로그인했을 때 쿠키에 sessionID가 없으면 서버에서 sessionID를 생성, 쿠키에 담아서 보낸다. 이제 쿠키에는 sessionID가 담긴 상태이기 때문에 로그인한 후 로그인한 상태를 유지하기 ..