포시코딩

개요 로그인된 상황에서의 API 테스트를 해야하는데 API 테스트 툴로 Thunder Client를 쓰고 있지만 어떻게 로그인 한 상태로 인식시켜 요청을 보낼지 감이 안잡혀 테스트를 못하고 있는게 있었다. 근데 사실 간단했음 현재 로그인 처리는 로그인 후 accessToken과 refreshToken을 발급해 Client에 던져주고 Client 쪽에서 알아서 cookie를 세팅한 상태로 API 요청할 때 Server에서는 cookie-parser를 통해 넘어온 cookie안의 acccessToken과 refreshToken을 사용하는 방식이다. 문제 파악 일단 client쪽에서 JavaScript를 통해 cookie를 저장한 상태로 API 요청할 때 header에 cookie가 포함되어 보내지는건 확인이..

우선 output 페이지 이동에 대해선 중간에 access token이 만료될 경우 refresh token을 통해 재발급 받고 index.ejs 페이지에서 모든 응답에 대해 받은 다음 재발급 받은 access token을 저장 후, 원래 요청하려면 페이지로 이동시키는 방식을 사용했다. output 로그인 되어 있을 시: res.locals에 userInfo (사용자 정보) 저장 및 전달 로그인 안되어 있을 시: userInfo 없어서 null 전달 middleware // access token, refresh token 모두 인증 통과 시 res.locals.userInfo = { id: userInfo.id, name: userInfo.name, point: userInfo.point, isAdmi..

개요 로그인 할 때 서버에서 res.cookie를 통해 저장하던 쿠키를 document.cookie로 프론트에서 저장하게끔 변경하고 난 뒤에 middleware 등 다른 여러 요청들에서도 server에서 직접 cookie를 설정하는 부분들이 있어 그 부분들을 수정하고 있었다. 그중 middleware에서 특이한 현상을 발견했다. access token이 만료되고 refresh token을 통해 access token을 재발급 -> 다시 메인 페이지로 return res.render('index', { redirect: req.path, message: 'access token 재발급', accessToken: newAccessToken, }); 보낸 뒤 새로운 access token을 다시 저장 후 요청..

오늘은 묵혀놓은 궁금한 것들을 해결하는 시간을 가져보았다. 구글링 및 그동안 공부한 것들 종합 + 튜터님한테 직접 물어보는 방법을 통해 아래 다섯가지 상황과 결과를 정리해보았다. api 통합 vs 분리 개요 대기중인요청 진행중인 요청 완료된 요청 위 세가지 요청 리스트 api에 대해 정리하던중 다시 path를 깔끔하게 재할당 해줘야하는 상황이 생겼는데 두가지 선택사항이 생겼다. 방법 찾기 1. 라우터에서 부터 나눠지게? /api/orders/waiting?p=1 /api/orders/doing /api/orders/done?p=1 2. GET /api/orders로 들어가 컨트롤러에서 type에 따라 다른 service 호출? /api/orders?type=waiting&p=1 /api/orders?ty..

https://github.com/9hezo/save_my_keyboard/blob/dev/app/src/middlewares/authMiddleware.js GitHub - 9hezo/save_my_keyboard Contribute to 9hezo/save_my_keyboard development by creating an account on GitHub. github.com 개요 'use strict'; const TokensService = require('../services/tokens.service'); const UsersService = require('../services/users.service'); const TokenManager = require('../config/TokenM..

HttpOnly 쿠키는 '세션 하이재킹', 'XSS 공격' 등으로 탈취될 수 있다. 대응 방법으로는 HttpOnly 설정을 추가해 HTTP Only Cookie를 활성화 시키면 XSS와 같은 공격을 차단할 수 있게 된다. 이렇게 되면 브라우저에서 해당 쿠키로 접근할 수 없게 되지만, 애초에 쿠키에 포함된 정보의 대부분이 브라우저에서 접근할 필요가 없기 때문에 기본적으로 적용하는 것을 권장한다. 하지만 HttpOnly 속성은 클라이언트(브라우저 등) 에서 설정할 수 없는 옵션이며 서버단에서만 설정할 수 있는 옵션이라는데 만약 프론트엔드 서버와 백엔드 서버가 분리되어 있다면 사용하기 힘든 상황이 발생할텐데 어떻게 해야할까? HTTP Only Cookie를 사용하면 Clinet에서 JS를 통한 쿠키 탈취 문제..

이번 주 알게 된 점 JavaScript 쿠키 저장 document.cookie = 'key=value' Map 자료형 key, value 꺼내기 const m = new Map(); m.set('a', 1); m.set('b', 2); m.set('c', 3); m.set('d', 4); m.forEach((value, key) => { console.log(value, key); }) // 1 a // 2 b // 3 c // 4 d MySQL 문법 LIKE SELECT student_name FROM students WHERE (track = 'Node.js' OR track = 'React') OR (student_name like '김%' OR student_name like '%호') CASE..

로그인 API의 Token 처리 before controller const response = await this.usersService.login(email, password); res.cookie('accessToken', response.accessToken); res.cookie('refreshToken', response.refreshToken); res.status(response.code).json({ message: response.message }); 기존에는 로그인 API 요청에 대해 모든 로그인 과정이 끝나면 백엔드에서 쿠키를 저장해줬었는데 쿠키를 생성하는 주체가 백엔드 서버가 되면 안된다는 피드백을 받았다. 프론트가 완전 분리 되어있다면 백엔드에선 쿠키를 만들어 전달하지 않습니다. ..

쿠키(Cookie) 브라우저가 서버로부터 응답으로 Set-Cookie 헤더를 받은 경우 해당 데이터를 저장한 뒤 모든 요청에 포함하여 보낸다. 데이터를 여러 사이트에 공유할 수 있기 때문에 보안에 취약할 수 있다. 쿠키는 userId-user-1321;userName=abcd 와 같이 문자열 형식으로 존재하며 쿠키 간에는 세미콜론(;)으로 구분된다. 쿠키(Cookie) 만들어보기 서버가 클라이언트의 HTTP 요청(Request)을 수신할 때, 서버는 응답(Response)과 함께 Set-Cookie 헤더를 전송할 수 있다. 그 후, 쿠키는 해당 서버에 의해 만들어진 응답(Response)과 함께 Cookie HTTP 헤더 안에 포함되어 전달받는다. Set-Cookie를 이용해 쿠키 할당하기 app.get..