예약 앱 개발 시 다른 회원의 예약 정보가 보이지 않게 하려면
예약 앱의 ‘내 예약’ 화면에는 내가 예약한 수업과 일정이 나와야 합니다. 다른 회원의 예약 시간이나 연락처가 함께 보인다면 문제가 됩니다. 로그인이 잘되는지와 회원마다 자기 예약만 볼 수 있는지는 따로 확인해야 합니다.
회원별로 예약 정보를 나누려면 서버가 로그인한 사람과 예약 주인을 확인한 뒤 허용된 정보만 보내야 합니다. ‘내 예약’ 목록과 예약 상세에서 이 규칙이 작동하는지 함께 확인해보겠습니다.
로그인한 회원과 예약한 회원이 같은지 확인합니다
수업을 예약하는 앱에서 회원 A는 오전 수업을, 회원 B는 오후 수업을 예약했다고 해보겠습니다. 두 사람 모두 일반 회원이고 정상적으로 로그인했습니다.
로그인은 지금 앱을 쓰는 사람이 A인지 B인지 확인하는 과정입니다. B가 A의 예약 상세를 요청하면 B가 그 예약을 볼 권한이 있는지도 확인해야 합니다. 본인 예약만 조회하는 서비스라면 B에게 A의 예약 정보를 보내면 안 됩니다.
그래서 ‘일반 회원은 예약 상세를 볼 수 있다’는 규칙만으로는 부족합니다. ‘일반 회원은 본인이 예약한 내역만 볼 수 있다’고 조회 범위를 구체적으로 정해야 합니다.
서버가 예약 주인을 확인한 뒤 정보를 보냅니다
앱에서 B가 자신의 예약 목록을 열면, 서버는 로그인 상태에서 확인한 B를 기준으로 B의 예약만 골라 보내야 합니다.
예약 상세를 열 때도 같은 확인이 필요합니다. 앱이 보낸 예약 번호만 보고 내용을 돌려주는 것이 아니라, 로그인한 회원이 그 예약을 볼 권한이 있는지 서버에서 확인해야 합니다. B가 A의 예약을 요청했다면 예약 내용을 보내지 않고 조회를 거절합니다.
이렇게 목록과 상세를 요청할 때마다 확인해야 어느 경로로 접근하더라도 같은 기준이 적용됩니다. 화면에 ‘내 예약’이라는 이름을 붙이는 것과 실제로 내 예약만 전달하는 것은 별개의 구현입니다.
화면에서 숨긴 정보가 서버 응답에 들어 있지는 않은지 봅니다
서버가 모든 회원의 예약 정보를 보내고 앱이 내 예약만 골라 보여주면 어떨까요? 화면은 정상처럼 보여도 다른 회원의 정보가 이미 기기까지 전달될 수 있습니다.
따라서 화면에서 다른 사람의 예약이 보이지 않는지와 함께, 서버가 보낸 응답에도 그 정보가 없는지 확인해야 합니다. 상세 조회를 거절할 때도 다른 회원의 이름이나 예약 내용을 오류 안내에 넣지 않도록 합니다.
발주자가 서버 응답을 직접 분석할 필요는 없습니다. 개발 담당자에게 화면과 서버 응답을 함께 확인하고, 확인한 결과를 설명해달라고 요청하면 됩니다.
두 계정으로 본인 조회와 다른 회원 조회를 비교합니다
개발사와 합의한 테스트 환경에서 일반 회원 A와 B를 만들고, 각자 구분되는 예약을 하나씩 준비합니다. 실제 고객 정보는 사용하지 않고, 두 계정은 로그인 상태가 섞이지 않는 별도 기기나 브라우저 환경에서 확인합니다.
- 본인 예약: A와 B가 각자 자신의 예약 목록과 상세를 정상적으로 볼 수 있는지 확인합니다.
- 목록 분리: A의 목록에 B의 예약이, B의 목록에 A의 예약이 섞이지 않는지 확인합니다.
- 다른 회원의 상세: 개발 담당자가 준비한 테스트 절차로 서로의 예약 상세를 요청하고, 조회 거절과 서버 응답의 예약 정보 미포함을 확인합니다.
개발사에는 확인할 범위를 이렇게 전달할 수 있습니다.
일반 회원은 본인의 예약만 조회할 수 있게 해주세요. 목록과 상세 조회 모두 서버에서 권한을 확인하고, 테스트 계정 A와 B로 본인 예약은 정상 조회되며 서로의 예약 정보는 전달되지 않는지 확인해주세요.
예약 취소나 수정 기능이 있다면 해당 행동의 권한도 따로 정해야 합니다. 위 절차로 확인하는 범위는 예약 정보의 조회입니다.
앱을 검수할 때 ‘내 예약이 잘 보인다’는 결과에 ‘다른 회원에게는 전달되지 않는다’는 결과도 함께 남겨보세요. 회원별 정보가 제대로 나뉘는지 더 구체적으로 확인할 수 있습니다.
데브크래프트의 로그인과 권한 확인 가이드에서는 주문 예시로 ‘내 주문 상세 보기’와 ‘다른 고객 주문 주소 열기’를 선택해, 정보 주인에 따른 허용·차단 과정을 비교해볼 수 있습니다.
