Private하게!

🤫 Private한 서비스

앞선 글에서부터 계속해서 Private 을 언급하는 것은, 이로부터 파생되는 개발의 방향성이 우리조의 독특한 점이라고 생각하기 때문이다.

개발 요구사항에 나와있는 Social이 개방적인 느낌을 주는 단어라서 Private과 Social의 절충안을 내는 것이 우리의 목표였다.

이에따라 우리는 다음과 같은 개발의 특징을 잡게되었다.

1️⃣ URL표기

URL에는 보통 해당서비스의 주소와 더불어 내가 보고있는 페이지의 정보가 들어간다.

예를들어, 지금 우리의 위키페이지의 URL은 https://github.com/boostcamp-2020/Project16-C-Account-Book/wiki 이다.

이것이 의미하는 것은, 누구든 저 URL을 통해 우리의 위키 화면에 접근할 수 있다는 것이다.

물론 권한에 따라 읽기만 가능한 경우와 쓰기까지 되는 경우로 나누어 처리되어있다. (다른곳으로 redirect 시키는 것도 가능하다.)

하지만, 어떤식으로 처리가 되었든지 누구든 해당 페이지로 접근 시도를 할 수 있음에는 변함이 없다.

반면, 우리가 생각한 가계부 서비스는 애초에 유저목록에 없는 외부인이 접근 시도자체를 못하게 하고 싶었다.

이에따라 URL에 가계부 고유아이디를 표기하지 않도록 개발을 하여서, 해당 화면에 접근하지 못하도록 하였다.

이러한 방식은 두 가지 한계점이 있었지만 각각 타협할만한 근거가 있기에 진행하였다.

1. history가 원하는대로 저장되지 않아서 브라우저의 뒤로가기 버튼이 원하는 대로 기능하지 않게 된다.

URL에 고유 id가 붙지않고, page 단위만 붙기 때문에 여러 가계부를 브라우저의 history 기능에 문제가 있었다.

예를들어, A의 가계부에서 /calendar, /chart, /transaction을 순서대로 이용한다음

다시, 가계부 목록인 / 로 이동한다.

그 다음 B의 가계부에 입장하여 다시 /calendar, /chart, /transaction을 순서대로 이용한다음

뒤로가기를 차례로 진행해보면, A의 가계부에 접근할 것이라고 기대되는 타이밍에 오류가 발생하게 되는 것이다.

URL history에는 A에 대한 어떠한 정보도 없었기 때문이다.

하지만, 우리가 계획한 시나리오에서 브라우저의 history 기능을 이용한 가계부간 이동은 극히 낮은 확률의 시나리오였다.

가계부 리스트 화면에서 굳이, 뒤로가기 또는 앞으로가기를 통해 특정 가계부에 접근하기보다는,

사용하고 싶은 가계부를 직접 선택하는 것이 매우 자연스러운 시나리오라고 생각했기 때문이다.

우리는 header디자인과 가계부 선택 UI를 좀 더 강조함으로써 서비스 내의 클릭을 통해 페이지를 이동하도록 유도하였다.

또한, 위에서 말했던 오류상황에서는 가계부 리스트화면을 유지하도록 하여 직접 선택을 하여 이동하도록 유도하도록 함으로써 한계점을 보완하였다.

2. 사실 가계부 고유 아이디자체를 완전히 Private하게 숨길 수는 없다.

URL에 가계부 고유 id값을 표기하지 않기 때문에, 해당 정보를 다른곳에 저장해두고 사용해야했다.

이때, 가계부 목록페이지의 카드 dom요소에 데이터를 심기로 결정하였다.

html dataset에 가계부 id를 심어두고, 가계부를 클릭할 경우 history의 location state를 통해 디테일 화면에 전달하도록 한 것이다.

외부인이 URL을 통해 가계부에 접근하는 것은 막았지만, 사실 이 dataset에 있는 가계부 고유 id가 어떤방식으로든 탈취 당한다면

악의적인 api를 날릴 수 있는 상황이 된 것이다. (사실 이럴 경우도 극히 낮은 시나리오라고 생각했다.)

최악의 경우인 api를 날릴 서버의 주소가 탈취당하고, 가계부 고유 id도 탈취당하고, api 라우팅 주소도 탈취당했을 때를 대비하여

결국 backend에서 최종적으로 권한에 대한 유효성 검증단계를 만들었다.

사실 이렇게 백엔드에서 유효성 검사를 진행하면, URL에 아이디가 노출되어 있더라도 외부의 접근시도에 대해 적절히 대응이 가능하다.

다만, URL에 아이디를 노출시키지 않는것이 애초에 접근 시도자체를 많이 봉쇄하는 느낌이기 때문에 그대로 진행하게 되었다.

2️⃣ slido 방식의 소셜기능

private 하면서도 social을 충족시켜야 한다는 생각이 들었을때,

가장 먼저 떠오른 것이 slido 서비스였다.

slido는 입장코드를 알고있는 사람들끼리 접근이 가능한 서비스이다.

즉, 공공재를 선택된 사람들끼리 사용하는 느낌인 것이다.

우리는 가계부에 접근을 허락해주고 싶은 사람에게만 초대코드를 알려주면 괜찮겠다는 생각을 하게 되었다.

이 초대코드는 휘발성의 해쉬값으로 만듬으로써 공유를 원하는 사용자가 입장하면, 손쉽게 새로운 값으로 바꿀 수 있도록 구현한다.

따라서, 아무나 막 들어오는 경우를 차단하는 것과 동시에 원하는 사용자와의 소셜기능도 구현할 수 있게 되었다.