점핑배틀외주 프로젝트2-url보안을 위한 프록시 서버 만들기

문제 분석

이번 에러에 유독 오랜 시간이 걸린 것은 요구사항에 대한 높은 이해가부족했기 때문이 가장 크다.
의뢰자의 요구사항은 저장소가 드러나는 것 만으로도, 대량의 요청을 한번에 전송하면 요금이 부과될 수도 있으므로 그것을 방지하게 해달라는 것이었는데
나는 이 이유에 대해 생각하지 않고 작업을 진행하다 보니 엉뚱한 식으로 구현을 하는 바람에 오랜 시간을 잡아먹었다.

잘못된 선택-base64인코딩

저 요구사항의 주요 포인트가 무엇인가?
당연 대량의 요청을 막기 위해->url주소를 가려주세요일 것이다.
우리가 가지고있는 것은 파일이 아닌 url이기 때문에 video src를 사용하기 위해서는 signedUrl이라는 우리의 저장소가 드러난 url을 사용하게 될 뿐 아니라, base64는 누구나 쉽게 디코딩을 할 수 있다.
또한, base64로 인코딩한 토큰을 넘긴다고 하더라도 src를 위해서는 클라이언트단에서의 디코딩이 불가피하기 때문에 처음부터 잘못된 생각을 했음을 알 수 있다.

signedUrl을 직접 사용하면?

아주 악질적인 유저가 expires를 변경한다거나 그 기간 내에서 유효하지 않은(의도하지 않은)요청을 무분별하게 보낼 수있다.
물론 우리 프로젝트의 경우 storage의 자동 삭제와 firebaseDatabase 통해 그런 경우 횟수의 카운팅이 넘으면 삭제를 지시하도록 하였으나, 짧은 시간내에 무분별한 요청을 보내는 유저에 대해 원천적인 해결책이 될 수는 없다.

프록시 서버 사용하기

프록시 서버란 일종의 안전을 위해 경유를 하는 경유 서버에 가깝다.
즉 중요한 정보를 감추기 위해 어떤 인코딩한 정보를 프록시에 넘겨주면, 프록시는 그 정보의 유효성을 검사하고 유효하다면 내가 원하는 형태로 뿌린다거나, signedUrl을 프록시서버에 값을 넘겨 유효성을 검출한 뒤 데이터만 남겨둔다면 프록시서버를 통한 동영상 재생이 가능하다.

이번 프로젝트에서의 프록시의 역할

클라이언트에서 프록시로 요청을 보내면 프록시에서는 내부 검증이후 파이어베이스의 signedUrl을 가져온다.
그리고 이 리소스 데이터를 클라이언트로 다시 보내는 것을 통해 의뢰자의 문제사안을 해결하였으나, 결론부터 말하자면 람다를 사용하는 프로젝트의 특성을 이해하지 못한 해결책이었다.