나를 위한 개발 정리 노트

발표 후에 들어온 질문이나 피드백이 많이 있었다. OAuth에 대한 부분 : 구글이나 깃허브는 표준을 따르고 카카오는 표준을 따르지 않는다. 그 차이를 알고 있으면 좋다. 이건 찾아보고 정리해서 알아둬야겠다. 패스포트를 이용해서 인증처리가 간편하게 되는 것만 알고 있었으며 소셜 로그인 모두 같은 표준을 따른 다고 생각했었다. 토큰 보관에 레디스 사용 : 지금은 작은 프로젝트라서 레디스 클라우드를 이용해서 작은 용량으로 처리할 수 있지만 실제 서비스에서는 좋지 않은 선택일 수 있다. 기업에서 레디스를 사용한다면 많은 비용이 발생한다. 그래서 토큰을 보관하는 것 정도는 레디스가 아니라 서버에 전역 변수를 만들어서 그 안에 저장을 해도 되고, mysql에 저장을 해도 충분히 속도적으로 문제가 없었을 것이다. ..

처음 해보는 유저 테스트가 끝났다. 분명 사전에 점검하고 문제가 없을 것이라 생각했지만 생각하지 못했던 에러들이 많이 생겼다. 그래서 급하게 원인을 파악해서 처리했다. 카카오 로그인의 경우 비밀번호가 없었기 때문에 회원 탈퇴 시에 비밀번호를 입력받아서 탈퇴처리를 할 수 없었으며 URL주소로만 접근해서 다른 사람의 게시글을 볼 수 있는 문제도 있었다. 그리고 아이폰에서 로그인을 못하는 문제와 이외에도 사용법이 어렵다는 의견과 사용법이 직관적이라는 의견이 대립되기도 했고 기획의도가 전달되지 않아서 사용자가 불편하게만 느껴지는 부분도 있었다. 가장 먼저 에러에 대한 부분을 처리하고 의견이 대립되거나 우리의 기획 의도와 다른 부분 의견에 대해서 그에 대해서 다시 회의를 하고 어떤 부분을 반영하고 어떻게 처리할지..

기존에 만들었던 회원탈퇴가 관리자 로그인으로 직접 삭제를 해야했기에 스케줄러로 자동으로 처리되게 했다. const CustomError = require("./error"); // CustomError를 불러옵니다. const confirmRequest = require("./confirmRequest"); const { Users } = require("../models"); const { Op } = require("sequelize"); class serverCheckDelete { async execute() { try { const maxListeners = 5; const timeoutDuration = 15 * 1000; let totalDeletedCount = 0; const timeou..

프로젝트 초기에 누군가 클라우디너리라는 CDN서비스를 소개하며 사용해보자고 했다. 이것은 자체적으로 이미지 저장 클라우드를 무료로 제공해주기 때문에 초기에 이미지 업로드는 프런트에서 진행했다. 하지만 이것에 보안적으로 좋지 않을 수 있다는 멘토링 시간의 조언을 듣고 찾아본 후에 백엔드에서 업로드 하는 것으로 변경했다. 그런데 왜 멀터를 사용해야하지 하는 의문이 생겼다. 기존에는 당연하게 멀터를 사용했는데 프런트에서는 멀터 없이 이미지 업로드를 처리했다. 그래서 멀터를 사용하는 이유를 찾으니 가장 큰 부분은 편의성이다. 개발자가 직접 복잡한 멀티파트 데이터 파싱 과정을 직접 구현할 필요가 없다. 그래서 코드가 간결해지고 유지 보수성이 좋아진다. 그리고 라이브러리 자체에 보안이나 에러처리, 확장성 등을 위한..

deleteAllUserInfo = async (req, res, next) => { const userId = res.locals.user; const { adminVerification } = req.body; const confirmRequest = req.confirmRequest; const maxListeners = 5; // 임계값 설정 const timeoutDuration = 15 * 1000; // 15초 let totalDeletedCount = 0; const timeoutFunc = (listener) => { return setTimeout(() => { confirmRequest.off('requestCompleted', listener); // 이벤트 리스너 제거 throw ..

서버 상태를 확인해야 하는 한다는 게 여러 방법이 있었는데 cpu나 메모리 등을 확인하는 방법 응답 시간을 확인하는 방법 처리 중인 요청의 수에 따라 처리하는 방법 이런 방법들이 하나만 사용되진 않고 각각의 장단점이 있기에 보완적으로 같이 사용된다고 한다. 그래서 나도 같이 적용시키고 싶지만 하나라도 제대로 만들자는 생각으로 하나만 선택해서 사용하기로 하고 요청 수에 따라 처리하는 방법을 찾아봤다. 처리 중인 요청의 수에 따라 처리하는 방법을 선택을 한 이유는 회원 탈퇴 뿐 아니라 처리가 제대로 이루어지고 있나 확인하는 용도로 사용할 수도 있으며 세부적으로 조정하기 쉽다는 장점이 있어 이런 시도를 처음 해보는 입장에서 테스트를 하기 쉬울 것이라고 생각이 되었다. 그럼 이것을 이제 어떻게 만들고 적용을 시..

회원탈퇴가 어떻게 보면 사용자가 느끼기에 엄청 중요하게 체감되는 기능이 아니고 별 신경을 안쓸 수도 있는 기능일 수도 있다. 하지만 다른 서비스를 사용하면서 회원탈퇴가 찾기 어려울 순 있어도 없는 경우는 못 봤다. 그래서 처음에는 크게 어렵지 않게 생각하고 만들려고 했었다. 그때는 이렇게 일이 커질 줄 몰랐다. 회원탈퇴하면 그냥 DB에서 정보를 지우고 참조되고 있는 테이블의 데이터를 다 지우면 되는 거 아닌가? 어떤 모임을 누군가가 만드는데 그것을 만든 사람이 탈퇴했을 때 그룹이 다 지워지면 같이 이용 중인 사람들에게 영향이 갈 수 있다. 우리의 서비스는 추억을 가장 큰 요소로 가져가는데 누군가 탈퇴했어도 그 사람이 작성한 게시글을 같은 모임의 사람들은 그래로 볼 수 있는 게 좋지 않을까 하는 의견도 나..

레디스 클라우드로 연결은 끝났다 그럼 이제 리프레시 토큰을 발급하고 이것을 레디스에 저장해야 한다. 토큰을 그럼 어떤 경우에 사용할까? 당연히 로그인했을 때 처음 발급 된다. 로그아웃을 한다면 토큰을 지워줘야 한다. 엑세스 토큰이 만료된 경우에 리프레시 토큰을 통해서 다시 재발급한다. 이때 액세스 토큰을 발급하는 API를 만들 수도 있지만 매번 새로운 엑세스 토큰을 발급받기 위한 과정이 불필요해 보인다. 한 번에 처리하는 방법이 없을까? 그래서 기존 토큰을 확인하던 미들웨어에서 토큰을 재발급하게 바꿨다. 회원 탈퇴를 할 경우에 탈퇴한 회원이기에 접근을 막기 위해 토큰을 지울 필요가 있다. 회원 가입을 하고 따로 로그인을 하는 것보다 바로 로그인이 되는 게 더 편할 것 같다. 회원가입 완료 시 로그인처럼 ..

진행 중인 프로젝트가 회원가입을 하고 로그인을 해야 서비스를 이용할 수 있었다. 그래서 사용자 인증을 무엇으로 하냐 고민을 했을 때 토큰이 더 적합해 보였다. 서버의 성능이 좋지 않다. 그런데 세션을 사용할 경우 서버에 성능이 더 저하될 가능성이 있다. 모바일 환경을 타겟으로 하는데 모바일에선 백그라운드에서 연결이 종료 되는 경우가 많다. 그래서 토큰을 이용하는데 이 때 토큰의 가장 큰 단점인 탈취 문제가 생긴다. 이를 해결하기 위해서 리프레시 토큰 로테이션 전략을 사용하려는데 리프레시 토큰을 서버에서 가지고 있을 수 있는 공간이 필요했다. 그래서 처음에는 사용자 정보가 있는 테이블에 같이 저장하려 했으나 로테이션 전략으로 인해서 사용한 리프레시 토큰을 바꿔줘야 하고 리프레시 토큰의 유효 기간이 지나도 ..

"async-mutex": "^0.4.0", "axios": "^1.5.0", "bcrypt": "^5.1.0", "cloudinary": "^1.40.0", "cookie-parser": "^1.4.6", "cors": "^2.8.5", "dotenv": "^16.3.1", "express": "^4.18.2", "express-async-handler": "^1.2.0", "express-session": "^1.17.3", "joi": "^17.9.2", "jsonwebtoken": "^9.0.1", "morgan": "^1.10.0", "multer": "^1.4.5-lts.1", "mysql2": "^3.5.2", "passport": "^0.6.0", "passport-kakao": "^1.0..