위 이미지와 같은 코드 작성을 통해 공란, 규격에 맞지않는 데이터를 받지 않도록 하였습니다
폼 작성 후 하단의 유저, 사장님 버튼을 누르시면 유저/사장님 회원으로 가입이 완료 됩니다.
2.3 유저 페이지
새로 가입한 회원의 유저 페이지 입니다
발제와 같이 첫 가입시 1,000,000 포인트를 증정하였습니다
하단의 표에는 세탁 서비스 신청 시 사용하게 될 데이터의 목록이 적혀있습니다
2.4 새로운 세탁 서비스 신청
해당 버튼을 누르시면 서비스 신청 페이지로 넘어갑니다
서비스 신청시 파일 선택을 통해 세탁물 이미지를 올리실 수 있습니다
물론 하지 않으셔도 좋습니다
하지만 소중한 빨래를 위해 요구사항은 꼭 작성 부탁드립니다.
요청 사항이 없으시다면 간단한 감사의 말을 전해보는 건 어떨까요?
오고가는 현금이 아니더라도 웃음 꽃은 핍니다
신청 완료 후의 서비스 내역 페이지 입니다.
10,000포인트가 차감되었고 유저 정보와 서비스 관련 사항들이 생겼습니다.
진행사항은 사장님 회원이 서비스를 진행하면 바뀝니다
리뷰는 세탁물을 돌려받으신 후에 작성할 수 있습니다
앞서 올리신 사진은 이미지 보기란 위에 마우스를 올리시면 보실 수 있습니다
2.4.1 서비스 수거 후
신청한 서비스가 채택되었을 때의 상태입니다
수거가 완료된 후의 모습입니다
배송이 완료된 모습입니다
이제 리뷰를 작성하실 수 있습니다
리뷰작성시 팝업창으로 리뷰 작성 화면이 뜹니다
깔끔
다른 유저의 페이지도 한번 보여드리겠습니다
2.5 사장님 페이지
사장님 페이지도 간결한 화면으로 구성되있습니다
새 유저인 만큼 포인트가 없습니다
그러면 세탁물 조회 페이지로 들어가보겠습니다.
위에 방금 가입했던 새유저가 신청한 세탁물이 있습니다
수락 버튼을 통해 세탁물을 가져갈 수 있습니다
다른 사장님보다 빠르게 가져가 봅시다
다시 사장 페이지로 나왔지만 업데이트가 있네요
수락한 서비스는 수거 중으로 뜨게 됩니다
업데이트 버튼을 통해 다른 수거 상태를 만들 수 있습니다.
아무것도 누르지 않았을 때의 수거 중
첫 업데이트 수거 완료
빨래가 완료 되었다면? 배송 중
이후 마지막 업데이트로 배송완료가 있습니다
이후엔 사장님이 업데이트 하실 수 없고 유저가 리뷰작성시
리뷰확인이 뜨게 됩니다
리뷰 확인페이지 입니다
손님의 상세한 리뷰가 좋네요
이번엔 다른 사장님의 서비스 내역을 보여드리겠습니다
보시면 4개의 서비스를 진행했지만 배송 완료가 된 빨래는 2건이라
총 2만 포인트를 획득한 걸 볼 수 있습니다.
3. 맘에 든 코드 설명
변다슬 님
이미 로그인 되어 있는 유저는 로그인 페이지에 접속하지 못하도록 해야 했다. 이부분 로직을 어떻게 해야 하나 막막했는데, 팀원분의 도움으로 해결 할 수 있었다. TOKEN payload값을 활용해 사용자를 구분할 수 있다는 점이 흥미롭게 다가왔고 많이 배울 수 있는 시간이었다.
김정민 님
자랑이라기 보단 피드백이 될 만한 코드여서 가져왔습니다. 현재는 Repository 에서 했지만 좀 더 보완해서 Service 에서 데이터 가공을 하는 방향으로 바꿀 수 있을거라고 생각합니다. 아쉬운 코드 이면서 제가 더 발전할 수 있을 것 같다는 생각을 가지게 되는 코드입니다.
박민욱 님
제 코드는 아니지만 시퀄라이즈 문법을 잘 몰랐는데 이 코드를 공부하고 나서 쉽게
응용할 수 있었기 때문에 마음에 드는 코드로 골랐습니다.
이재관 님
form태그에서 submit버튼으로 데이터 받아오는 코드라 넣어봤습니다.
조봉진
코드보다는 모듈화와 Layered Architecture Pattern에 이해가 전혀 가지 않았는데
팀원들의 도움으로 전체적인 맥락이 조금이나마 이해하게 된거 같았고
구조가 인상깊었습니다.
이상으로 프로젝트 설명을 마치겠습니다
하단은 SA문서에서도 보실 수 있는 내용으로 앞서 보셨다면 보실 필요 없습니다.
4. 프로젝트 SA
프로젝트 제목/간단 설명
팀 이름
경기도민
팀 이름 설명
팀원 모두 경기도에 사는 것을 바탕으로 결정
팀원
김정민, 박민욱, 변다슬, 이재관, 조봉진
프로젝트 명칭
세탁 프로젝트
프로젝트 설명
이용자들이 세탁 서비스 신청 시 사장이 선택할 수 있음
이용자들이 세탁 서비스에 대한 리뷰를 달 수 있음
세탁물의 상태를 대기 중, 수거 중, 수거 완료, 배송 중, 배송 완료 다섯 단계로 알 수 있음
Access Token은 사용자의 권한이 확인(ex: 로그인) 되었을 경우 해당 사용자를 인증하는 용도로 발급하게됩니다.
Cookie로 jwt를 발급하고 설정한 Expire 기간이 지날 때 인증이 만료되게 하는것 또한 Access Token이라고 부를 수 있다.
사용자가 Access Token을 가지고 인증을 요청할 경우 Token을 생성할 때 사용한 **비밀키(Secret Key)**를 가지고 인증하기 때문에, 복잡한 설계없이 코드를 구현할 수 있고, 여러 분기를 거치지 않아도 된다는 장점이 있다.
Access Token의 경우 Stateless(무상태) 즉, Node.js 서버가 죽었다 살아나더라도 동일한 동작을하는 방식. 즉, jwt를 이용해 사용자의 인증 여부는 확인할 수 있지만, 처음 발급한 사용자 본인인지 확인할 수는 없다.
Access Token은 그 자체로도 사용자를 인증하는 모든 정보를 가지고 있다. 그렇기 때문에 토큰을 가지고 있는 시간이 늘어날 수록 탈취되었을 때는 피해가 더욱 커지게 됩니다.
만약 토큰이 탈취되었다고 인지하더라도 저희들은 해당 토큰이 탈취된 토큰인지 알 수 없고, 고의적으로 만료를 시킬 수도 없을 것 입니다. 그러므로 저희들은 언제든지 사용자의 토큰이 탈취될 수 있다고 생각을 하고, 피해를 최소화 할 수 있는 방향으로 개발을 진행해야합니다.
Refresh Token은 Access Token 처럼 해당하는 사용자의 모든 인증 정보를 관리하는 것이 아닌, 특정한 사용자가 Access Token을 발급받을 수 있게 하기 위한 용도로만 사용된다.
Refesh Token은 사용자의 인증정보를 사용자가 가지고 있는 것이 아닌, 서버에서 해당 사용자의 정보를 저장소 또는 별도의 DB에 저장하여 관리한다. 그렇기 때문에, 서버에서 특정 Token 만료가 필요할 경우 저장된 Token을 제거하여 사용자의 인증 여부를 언제든지 제어가 가능하다는 장점이 있다.
그렇다면 어째서 바로 Access Token을 발급하지 않고, Refresh Token을 거쳐서 Access Token을 발급하는것일까요? 사용자에게 발급한 Token이 탈취당할 경우 피해를 최소화 하기 위해서 사용합니다.
저희가 실제 세계에서 사용하는 OTP와 같이 짧은 시간 내에서만 인증 정보를 사용할 수 있게하고, 주기적으로 재발급하여, 토큰이 유출되더라도 오랜 기간동안 피해를 입는것이 아닌, 짧은 기간동안만 사용가능하도록 하여 피해를 최소화할 수 있게 됩니다.
언제든지 토큰이 탈취될 수 있다는 것을 가정하고, 탈취를 막는것이 어렵다면, 우리는 탈취된 토큰자체를 사용할 수 있는 기간을 줄여서 피해를 막을 것 입니다.