[Sessac] 프로젝트 회고록_CRUD

안녕하세요

제 인생 첫 개발 프로젝트에 대한 회고록을 작성하려고 합니다.

 

수업 시간에 배웠던 것들을 잘 활용하고, 팀원과 원만하게 의사소통하며

프로젝트를 마무리 하는 것이 제 온전한 목표였기 때문에 별로 작성할 것이 없다고 생각하였지만,

 

그래도 마무리를 하며, 제가 더 나은 방향으로 나아가기 위해 회고록을 써보고자 합니다.

---

저는 백엔트 포지션에 지원하여, 각각의 어느 정도 담당 영역이 있어야한다고 생각하여

역할을 나누다가 회원 및 관리자 담당을 하게 되었습니다.

 

(랜덤으로 맡아진 역할이라서) 어떤 역할이든 열심히 할 생각이었지만

모든 사이트에서 가장 기본이 되는 유저 관리와 관리자 페이지를 맡게 되었습니다.

기왕 맡게 된 거 플랫폼 운영 마케터로 일했던 경험을 살려서 관리자 페이지에 녹이려 하였습니다.

 

제가 작성한 USER 라우터의 개수는 30개로, 해당 프로젝트에서 제일 많은 기능을 지니고 있습니다.

사이트 내 모든 기능와 회원은 연결되어있는 개체이다 보니 많은 기능들과 얽혀있어서

덕분에 다른 기능도 아울러 코딩할 수 있는 기회였습니다.

 

일단 모든 로직을 하나하나 설명할 수 없으니,

제가 프로젝트를 진행하며 겪었던 이슈와 극복과정을 위주로 공유하도록 하겠습니다.

 

 

1. 비밀번호 암호화로 인한 문제

저는 bcrypt 모듈을 통해 암호화를 진행하였습니다. 

bcrypt는 비밀번호 해시 알고리즘을 구현하고 제가 원하는 길이 만큼의 솔트를 사용하여

사용자의 비밀번호를 그대로 DB에 저장하는 것이 아닌, 암호화된 상태를 DB에 저장하도록 하였습니다.

 

DB에는 아무도 모르는 비밀번호 암호된 내역이 들어가 있으니,

회원이 회원가입을 하고 로그인을 진행할 때에도, DB에서 암호화된 입력 비밀번호가 똑같을 시에만

로그인이 진행되도록 구현하였습니다.

 

그러나 문제는 회원 수정 페이지에서 비밀번호를  새로 입력하지 않고

다른 부분만 수정하여 DB에 업데이트 할 경우, DB에 비밀번호를 암호화한 문자열을 또 해시 암호화해서

올라가게 되어, 재로그인이 안된다는 이슈가 있었습니다.

 

---

이는 조건문으로 사용자가  비밀번호를 업데이트하는 경우와 하지 않는 경우로 나누어서

업데이트 하는 내용을 다르도록 if문을 활용해 바꾸었습니다.

 

또 프론트 쪽에서는 수정 페이지에서 아예 해시 암호화된 내역이 뜨지 않도록 빈칸으로 두되,

사용자가 알 수 있도록 새로운 비밀번호라고 명시해주었습니다.

 

---

2. url을 통한 타인 회원 페이지 접근 가능 및 관리자 페이지 접근 가능

 

저는 아무래도 작은 프로젝트이다 보니, 보안에 관련해서 깊게 생각하지 않았는데요

그런 제게 보안에 관련해서 경각심을 가지게 해준 이슈입니다.

git issue 관리에 써놓은 issue

회원정보 수정 페이지와 관리자 페이지는 url에 있는 회원id값을 이용하여 구분하도록 해놓았습니다.

그러다 보니 전혀 다른 유저가 회원정보 수정 페이지에서 id값만 바꾼 URL로 접속을 하게 되면

그대로 해당 id값이 해당하는 회원의 정보 페이지가 노출이 되었습니다.

---

 

이는 조건문을 사용하여 세션이 있는 경우와 세션이 없는 경우로 나누고,

유저 세션이 있는 경우에는 그 세션값의 회원 id값이 일치하는지 점검하는 로직으로 controller를 전면 수정하였습니다.

 

세션이 없는데 URL을 통해 회원정보 수정 페이지로 접근한다면, 로그인 페이지가 뜨도록 하고

세션이 있는데 접근하고자 하는 회원 수정 페이지와 본인의 세션 id값이 다르다면 404페이지가 뜨드록 하였습니다.

이 일을 계기로, 팀원들에게도 보안에 관련된 사항들을 늘 주의하며 나누도록 하였습니다.

가령, console.log를 통해 페이지 정보가 함부로 노출되지 않게 늘 지우라고 강조하였습니다.

 

또한 config파일은 .gitingnore에 추가하여 저희만 갖고 있는 파일로 설정하되,

그 안에 세션 이름을 random으로 갖고, secret key도 철저하게 관리하였습니다.

 

보안에 관련하여 잘 모르지만, 저희가 할 수 있는 보안 이슈를 최대한 막고자 하였으며

앞으로 보안에 대한 공부를 더 해야겠다고 생각하였습니다.

---

3. 세션이 많은 방면에서 필요했음

 

사용자 로그인을 유지하려면 header에 session을 넣고

유지하는 미들웨어가 필요하다고 판단되었습니다.

 

수업 시간에 실제 배우진 않았지만, 인터넷에 정보가 상당하여 넣기로 하였습니다.

---

먼저 모든 정보가 들어있는 최종 파일인 app.js에 cookie와 session에 대한 모듈을 불러왔습니다.

 

그리고 local을 이용하여 header에 session을 넣어주었습니다.

 

 

if문 안에 들어가기 전에 locals에 기본값을 넣어주지 않게 되면,

에러가 일어나서, 일단 기본값을 넣어서 넘겨주고 만약 기존 세션이 있다면

값을 바꾸도록 로직을 짰습니다.

 

실제 헤더 안에서는 locals로 접근하여 다양하게 활용하였습니다.

---

4. 관리자 페이지의 비효율성

 

관리자 페이지를 호기롭게 만들었으나, 관리자가 1명이라는 가정 하에,

행사를 승인하고 거절할 수 있는 시스템을 만들었습니다.

 

관리자 페이지 중 행사 관리 페이지

 

관리자가 여러명이라면 다 다른 관리자임에도 불구하고

행사 등록 완료 목록과 거절 목록이 동일하게 보일 수 있도록 구현하였습니다.

 

이는 굉장히 비효율적이고, 추후 이 사이트의 관리자들이 관리할 때 어려울 것이라고 느꼈습니다.

제가 플랫폼 운영을 하며 광고 관리자로서 운영을 할 당시, 

전체 광고 리스트에서 제가 관리하고 담당하는 광고를 찾아야할 때 번거로움을 느꼈기 때문입니다.

---

그리하여 DB의 행사 관련 테이블에 마지막 column으로 승인한 관리자 column을 추가하였습니다.

이 행사가 승인되었다면 어떤 관리자가 승인하고 거절했는지 관리자의 id값이 들어가도록 구현하였습니다.

 

승인 예정(대기) 중인 행사는 모든 관리자가 동일하게 현황을 볼 수 있도록 하였고,

특정 관리자가 승인하거나 거절했다면 그 관리자의 계정 페이지에만 해당 행사를 볼 수 있도록 하였습니다.

 

구현 자체는 column만 추가하고 update항목을 추가한 것이라서 어렵지 않았는데,

관리자의 입장에서 조금 더 생각해보려고 하였습니다.

 

다음에는 동시에 승인 버튼을 눌렀을 경우 등등 상세한 항목에 대해

예외처리를 할 수 있는 개발자가 되고 싶습니다.

 

끝 -------------------