서명된 주소로 직접 업로드

앱 서버가 권한 확인과 서명 발급만 하고 파일은 클라이언트가 스토리지로 직접 보냅니다.

1) 클라이언트가 앱에 업로드 허가를 요청한다
2) 앱이 권한을 확인하고 조건이 박힌 서명 주소를 내려준다
3) 클라이언트가 그 주소로 파일을 직접 올린다
4) 스토리지가 서명과 조건을 검증한다

얻는 것은 앱이 경로에서 빠지는 것입니다. 파일 크기와 동시 업로드 수가 앱의 대역폭과 스레드에 영향을 주지 않습니다.

흔한 실수: 서명을 "인증 토큰"으로만 설명하는 것. 서명은 조건이 붙은 허가이고, 만료와 크기 상한과 콘텐츠 타입과 대상 경로를 담습니다. 조건을 넣지 않으면 유출 시 영구 업로드 권한이 되고 남의 경로에도 쓸 수 있습니다.

끊기지 않습니다. 만료는 업로드를 시작할 수 있는 기한이고 전송 시간 제한이 아닙니다.

서명을 제시해 전송이 시작되면 그 연결은 유지됩니다. 그래서 만료는 사용자가 파일을 고르고 업로드를 누르기까지의 시간만 덮으면 되고, 몇 분이면 충분합니다.

다만 멀티파트로 나눠 올리면 파트마다 요청이 새로 나가므로, 전체 업로드가 만료보다 길어질 수 있습니다. 이때는 만료를 조금 늘리거나 파트 서명을 다시 받는 경로를 둡니다.

흔한 실수: 큰 파일을 위해 만료를 길게 잡는 것. 전송 시간과 시작 기한을 혼동한 것이고, 유출 위험만 늘립니다.

모릅니다. 따로 만들어야 합니다. 앱이 경로에서 빠진 대가입니다.

실무에서는 둘을 함께 씁니다. 클라이언트 통보를 빠른 경로로 쓰고, 스토리지 이벤트를 안전망으로 둡니다. 둘 다 같은 파일을 알릴 수 있으니 처리는 멱등해야 합니다.

한쪽만 두면 문제가 남습니다. 클라이언트 통보만 두면 통보 없이 스토리지에만 남은 파일이 쌓이고, 이벤트만 두면 사용자가 업로드 직후 화면에서 파일을 못 봅니다.

흔한 실수: 클라이언트 통보만으로 끝내는 것. 모바일에서 앱이 백그라운드로 가거나 죽는 것은 정상 상황이고, 그때마다 고아 객체가 생깁니다.

서명 조건에 넣어야 합니다. 화면이나 클라이언트 검사는 통제가 아닙니다.

클라이언트는 고쳐 보낼 수 있는 쪽입니다. 업로드 화면에서 크기를 검사해도, 요청을 직접 만들어 보내면 그대로 통과합니다.

같은 이유로 콘텐츠 타입과 대상 경로도 서명에 넣습니다. 경로를 넣지 않으면 남의 파일을 덮어쓸 수 있고, 타입을 넣지 않으면 이미지 자리에 실행 파일이 들어옵니다.

흔한 실수: 서명 발급 요청에 클라이언트가 보낸 파일명과 크기를 그대로 믿고 서명에 박는 것. 값 자체가 클라이언트에서 온 것이므로, 허용 범위는 서버가 정한 정책과 대조해서 결정해야 합니다.