whenever purple

프로젝트: Social Study Network (SSN: 쓴)    *프론트엔드와 첫 협업프로젝트

설명: 팀원들, 학교친구들과 공부시간을 공유하며 응원할 수 있는 소셜네트워크 사이트입니다.

제작: 2022.04.08~2022.04.14

시연영상: https://youtu.be/ZAMqhx5jCNU

깃허브: https://github.com/ymkwon3/ssn (프론트엔드) / https://github.com/moonhjang/miniproject_back (백엔드)

노션: https://www.notion.so/d556601ee2de4629a9a1947675f23dd6

와이어프레임

사용 기술

• Server: AWS EC2 (Ubuntu 18.04 LTS)
• Framework: Express (Node.js)
• Database: MongoDB (Mongoose)
• JWT (Json Web Token)
• Crypto-js
• CORS
• Front-end: React

핵심 기능

• 로그인/ 회원가입 페이지
  • 아이디 패쓰원드 입력 가능
  • 로그인 시, 토큰전달 (모든페이지에서 해당 토큰확인 기능)
  • 빈칸 및 아이디 형식(4자이상, 대소문자, 숫자, 특수문자(!@#"-_)) 확인 가능
  • 회원가입시 아이디/닉네임 중복검사
  • 비밀번호 재확인 일치 확인 가능
• 메인페이지
  • 해당 유저와 친구리스트 조회
  • 공부시간 시작/정지 버튼
  • 총 공부시간 조회가능
  • 친구 추가가능
  • 친구와 공부시간 순위 확인가능
  • 친구의 공부시간 및 접속 확인 가능
• 방명록 페이지
  • 등록된 친구 방명록에 코멘트 조회, 작성 가능
  • 방명록 주인과 방명록 작성자만 삭제 가능
  • 본인 방명록 페이지에서는 상태메세지 수정 가능

Trouble Shooting   

▶ Auth-Middleware에 대해 프론트 업무에 대한 이해부족했다.

→ 개인프로젝트 진행시, 로그인 실행시 로그인인증 확인API도 함께 확인되었다. 그때, 로컬스토리지에 유저 정보를 넣어두었다. 하지만 프론트에서 로그인인증 확인하는 방법이 따로 있기 때문에 굳이 필요없어 제외를 했다. 저장된 토큰으로 모든페이지의 로그인 인증확인하는 방법을 동일하여 문제없이 작동되었다. 

▶ 로컬에 있는 MongoDB를 사용하고자 했지만, 로컬DB의 내용을 확인하려고 하니 배포과정에서 오류가 발생하였다. 

→ 로컬DB를 사용하지 않고 MongoDB클라우드에 직접 연결하여 실행하였다. 

▶ _id를 commentid 로 사용하게 되면서, _id를 백엔드에서 object에서 string으로 객체 type을 변경해야하는 점에서 어려웠다.

→ Comment 스키마에서 _id를 commentid로 만들어 string으로 변경하여 전달하였다. 

개인회고

첫 프론트엔드와의 협력프로젝트였다. 프론트업무에 대한 지식이 부족했기에 표현방식과 이해하는 방식이 굉장히 달랐다. 프로젝트 중반부터는 서로의 업무를 이해하고 나니 생각보다 프로젝트가 문제없이 풀렸다. 

개인 프로젝트시에는 내 작업을 웹사이트에서 확인하는 것이 편했는데, 협력할 때는 확인할 수 없는 뷰가 없어서 불편했다. 썬더 클라이언트가 그 역할을 대신했지만, 회원가입이나 로그인 시 전달되는 정보를 직접작성해야하는 번거로웠지만 잘 적응 할 수 있었다. 특히, 모든페이지를 auth-middleware로 연결 후에는 토큰이 없기에 썬더 클라이언트를 사용할 수 없었다. (이후 알아보니, 헤더에 토큰을 넣어 확인해볼수 있다는 것을 알게되었다.) 

협력했던 프론트 분이 굉장히 잘하시던 분이라, 밴엔드로서 굉장히 도움도 많이 받았고 수월하게 프로젝트를 진행할 수 있었다. 프로젝트 진행시, 염려했던 CORS 이슈나 auth-middleware(인증미들웨어)에 대한 이슈는 거의 없었다. 배포 초반, 인증 미들웨어에 대한 약간의 이슈가 있었으나 콘솔찍으면서 전달하고 전달받는 데이터를 확인하니 큰 이슈없이 해결되었다.

굉장히 만족스러웠던 점은 모든 기능들이 문제없이 잘 작동했고, 모든 팀원들 또한 만족스럽게 끝낸 프로젝트라서 더 좋았다. 우리 팀원 모두 흥해라!

항해99 5주차에는 프론트엔드와 백엔드가 함께 미니프로젝트를 진행하게 되었다.

그전에도 CORS 모듈을 설치에 진행하는 것이 좋다라고만 들었는데, 

프론트 작업과 연결시 필요한 작업이기에 CORS를 자세히 알아보기로 했다.

CORS란?

CORS(Cross-Origin Resource Sharing), 교차 출처 리소스 공유라고 해석된다. 
CORS정책은 우리가 가져오는 리소스들이 안전한지 검사하는 관문이다. 

웹 개발을 하다보면 CORS 정책 위반으로 인해 에러가 발생한다. 콘솔에서 아래와 같은 메세지를 확인할수 있다.

CORS 관련 이슈는 모두 CORS 정책을 위반했기 때문에 발생한다.

위의 에러는 CORS를 허용해서 아무런 탈 없이 다른 출처 리소스를 공유해달라는 권고사항과 같은 것이다.

CORS라는 방어막 덕분에 우리가 이 곳 저 곳에서 가져오는 리소스가 안전하다는 최소한의 보장을 받을 수 있다.

출처 (Origin) 란?

서버의 위치를 의미하는 URL은 Protocol, Host, Port 까지를 의미한다. 

웹에는 SOP(Same Origin Policy) 와 CORS(Cross Origin Resource Sharing) 두가지 정책이 있다.

▶ SOP(동일 출처 정책) ◀

같은 출처에서만 리소스를 공유할 수 있다" 라는 규칙을 가진 정책

→ URL의 구성요소 중 Protocol, Host, Port 세가지 동일한지 확인한다.

→ 같은 Protocol, Host, Port을 사용한다면 요소는 다르더라도 같은 출처로 인정된다.

→ 리소스가 자신의 출처와 다를경우, 브라우저는 교차출처 요청을 실행한다. 

즉, Protocol, Host, Port 중 하나라도 일치하지 않으면 Cross Origin 이라고 한다. 

▷ 실무에서 참고하자면 ◁

프론트 서버와 백엔드 서버 연결시

프론트 서버 URL이  http://localhost:3000,

백엔드 서버 http://localhost:8080 일때

SOP 정책에 어긋나기때문에, 서버로부터 응답이 넘어올 때 

브라우저에서 CORS 정책 오류를 발생시킨다. 

▶ CORS (교차 출처 리소스 공유) ◀

추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 어플리케이션이 다른 출처의

선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에게  알려주는 체제이다. 

CORS 동작방식

1. 클라이언트에서  HTTP요청 헤더에 Origin을 담아 전달한다. 

2. 서버는 응답헤어에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다.

3. 클라이언트에서 자신이 보냈던 요청의 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다. 

자신이 보낸 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교하여 차단할지 말지 결정한다. 

만약 유효하지 않다면 그 응답을 사용하지 않고 버린다. 

(위의 경우 둘다 http://localhost:3000 이기 때문에 유효한 경우다.)

아래의 블로그를 참고하여 작성되었습니다.

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-CORS-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95-%F0%9F%91%8F

프로젝트 : 로그인/회원가입 페이지

설명 : 로그인, 회원가입, 게시글 코멘트 등록, 조회, 수정, 삭제 기능구현 연습을 위해 제작되었습니다. 

제작 : 2022.03.25 ~ 2022.03.31

시연영상: https://youtu.be/sNPd6aWwgQM

깃허브:  https://github.com/moonhjang/node_1

사용 기술

• Server: AWS EC2 (Ubuntu 18.04 LTS)
• Framework: Express, Mongoose(Node.js)
• Database: MongoDB
• front-end: HTML5, CSS3, Javascript, Jquery, bootstrap

핵심 기능

• 회원가입페이지
• 로그인 페이지 
• 로그인 검사
  • 조회페이지 제외, 로그인 한 경우만 볼수 있도록 하기
• 댓글
  • 로그인한 사용자만 댓글 추가/ 수정/ 삭제

Trouble Shooting

▶ 인증이 필요한 페이지와 인증미들웨어를 연결되어있지만, 안내 알람이 JS파일이 아닌 HTML파일의 알람을 띄우는 이슈가있었다. 

→ 인증 미들웨어.js와 router.js 이 제대로 연결되어 있지 않았다. 로그인시, 미들웨어와 연결된 로컬스토리지에 잘못된 인증키가 들어가게 되면서 인증 키를 제대로 전달해주지 못하면서 생겨난 이슈였다. 연결이 잘 되면서 알림이슈는 해결되었다. 

▶ 댓글 추가시, mongoDB의 subdocument이용방법으로 댓글을 추가하였다. 이와 같은 방법으로 조회를 하려고 했지만 예상치 못한 오류로 작동이 되지않았다.

→ 예상치 못한 오류를 잡기위해서 Try-Catch문을 이용하여 해결되었다.

+ 지난주 작업에서 아쉬웠던 비밀번호 암호화 처리 및, env 파일과 .gitignore을 사용하여 보안을 강화하였다.