https://team-edo.github.io/tags/%EC%84%9C%EB%AA%85-url/Recent content in 서명 URL on 얼쑤 · Team EdoHugoko-krTue, 03 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/cors-after-audio-redirect/Tue, 03 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/cors-after-audio-redirect/<p>얼쑤의 모범 연주 음원 API를 Swagger에서 확인하다가 <code>Failed to fetch</code>를 만났습니다. 같은 음원의 처음 2바이트를 <code>curl</code>로 요청하니 저장소는 HTTP 206을 반환했습니다. 저장소가 바이트를 보내고도 브라우저에서 읽을 수 없는 이유를 찾으려면, 처음 요청한 API와 음원을 실제로 돌려주는 서버를 나눠 봐야 했습니다.</p> <h2 id="302-뒤의-응답을-확인했다">302 이후의 응답 추적</h2> <p>Swagger 페이지와 음원 API는 같은 출처에 있었습니다. API는 곡과 음원의 게시 상태를 확인한 뒤 HTTP 302의 <code>Location</code> 헤더에 R2 서명 URL을 담았습니다. 브라우저가 리다이렉트를 따라가면 음원 본문은 다른 출처인 R2에서 내려옵니다. 그 응답에는 Swagger 페이지의 출처를 허용하는 <code>Access-Control-Allow-Origin</code>이 없었습니다. 브라우저는 저장소 응답을 받았지만 페이지의 자바스크립트에 넘기지 않았습니다. <a href="https://fetch.spec.whatwg.org/#cors-check">Fetch 표준의 CORS 검사</a></p>https://team-edo.github.io/posts/2026/11/playback-url-store-boundary/Mon, 02 Nov 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/11/playback-url-store-boundary/<p>얼쑤의 녹음 다시 듣기 API에 기존 저장소의 읽기 주소 발급 기능을 연결했습니다. 로컬 저장소에서는 분석 컨테이너가 쓰는 내부 주소가 HTTP 200 응답에 들어왔습니다. 테스트는 그 주소의 호스트를 테스트 프로세스가 접근할 수 있는 주소로 바꿔 읽었기 때문에 성공했습니다. 휴대폰은 응답에 들어 있는 주소 그대로 접속하므로 같은 결과를 기대할 수 없었습니다.</p> <h2 id="주소를-받을-쪽을-기준으로-연결을-나눴다">앱이 접근할 주소만 발급</h2> <p>DB의 <code>recording_url</code>에는 녹음 원본을 찾는 객체 키를 저장합니다. 앱에 넘길 임시 주소는 그 키로 다시 듣기를 요청할 때 따로 만듭니다. 그래서 같은 세션의 객체 키를 읽어도 연결한 저장소에 따라 앱이 사용할 주소를 발급할 수 있는지가 달랐습니다.</p>https://team-edo.github.io/posts/2026/10/keep-signed-urls-out-of-analysis-errors/Wed, 28 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/keep-signed-urls-out-of-analysis-errors/<p>얼쑤의 분석 서버는 요청에 담긴 서명 URL로 녹음을 내려받습니다. URL에 읽기 권한이 담겨 있어 유효 시간 안에는 주소만으로 파일을 요청할 수 있습니다. 분석 API를 구현할 때 이 주소가 어디에 남는지 점검했습니다. 제가 작성한 코드에서 URL을 로그에 쓰지 않아도 두 곳에 남을 수 있었습니다. 요청을 검증하는 프레임워크의 응답과 녹음을 내려받는 HTTP 라이브러리의 로그입니다.</p> <h2 id="bpm을-틀리게-보냈을-때는-문제가-드러나지-않았다">BPM을 누락해야 드러난 응답 노출</h2> <p>당시 FastAPI 기본 검증 응답은 HTTP 422와 함께 오류가 난 입력값을 <code>input</code>에 넣었습니다. <code>bpm</code>에 0을 보내면 오류의 입력값도 0이었습니다. 이 경우만 검사하면 기존 처리기를 써도 서명 URL이 응답에 없었습니다. <code>bpm</code>을 아예 빼자 검증기가 그 필드가 있어야 할 요청 객체를 오류에 담았습니다. 같은 객체의 <code>audioUrl</code>도 응답에 실릴 수 있었습니다.</p>https://team-edo.github.io/posts/2026/10/recording-storage-signed-read/Tue, 27 Oct 2026 00:00:00 +0900https://team-edo.github.io/posts/2026/10/recording-storage-signed-read/<p>얼쑤에서 연습 녹음을 받으면 백엔드는 원본을 객체 저장소에 보관하고, 분석 서버는 필요한 파일을 가져와 처리합니다. 처음에는 서울 리전과 신규 계정 크레딧을 고려해 Google Cloud Storage(GCS)를 쓰는 설계를 잡았습니다. 다음 날에는 크레딧이 끝난 뒤의 비용과 다운로드 조건, 저장소를 바꿀 때의 구현 부담을 다시 검토해 S3 호환 API를 쓰는 Cloudflare R2로 계획을 바꿨습니다.</p> <h2 id="분석-서버에는-15분-동안-한-파일을-읽을-권한만-준다">한 파일에 15분 읽기 권한</h2> <p>분석 서버가 해야 할 일은 전달받은 녹음 한 건을 읽는 일이었습니다. 그래서 백엔드가 특정 객체에 대해 <code>GET</code> 요청만 <strong>15분(900초)</strong> 동안 허용하는 URL을 서명하고, 분석 서버는 그 주소로 원본을 내려받도록 했습니다. 저장소의 자격 증명은 서명하는 백엔드에만 둡니다. 유효한 URL을 가진 사람도 파일을 읽을 수 있으므로 주소 자체를 노출하지 않는 것도 이 설계의 일부입니다. <a href="https://docs.cloud.google.com/storage/docs/access-control/signed-urls">Google Cloud Storage 서명 URL</a> · <a href="https://developers.cloudflare.com/r2/api/s3/presigned-urls/">Cloudflare R2 서명 URL</a></p>