fix(afternote): 수신자 증빙 업로드 재발 — presigned 요청에 BE 필수 필드 contentLength 누락으로 400 #915

Activity

1. OnlyReadOneBook

   self-assigned this

   on Aug 23, 2026
2. OnlyReadOneBook commented on Aug 25, 2026

   

   OnlyReadOneBook

   on Aug 25, 2026

   CollaboratorAuthor

   More actions

   재현 재확인 + 계약 변경 시점 특정 (develop 4e0a648eb, 2026-08-25 17:53 KST)

   앱에서 수신자 인증 3단계(증빙 서류 업로드)까지 실제로 진행해 파일을 첨부했더니 동일하게 400입니다.

   POST /api/v1/receiver-auth/presigned-url  --> END POST (19-byte body)
   <-- 400 (1290ms)
   

   body 19바이트 = {"extension":"png"} 만 나갑니다. 이 지점에서 막혀 4단계 인증을 앱으로 완주할 수 없습니다(1·2단계 이메일/마스터키는 정상 통과).

   BE 계약이 언제 바뀌었나

   contentLength 필수화는 BE 커밋 27fa442(2026-08-09, "fix: S3 staging 누수 차단과 업로드 크기 상한") 에서 들어왔습니다.

   + @NotNull(message = "파일 크기는 필수입니다.")
   + @Positive
   + Long contentLength   // ReceiverPresignedUrlRequest 에 추가

   즉 8/9에 서버가 계약을 조였고 FE 가 반영하지 않은 상태입니다. FE 로직 버그가 아니라 계약 동기화 누락입니다. 같은 커밋이 일반 이미지 PresignedUrlRequest 도 함께 바꿨으니, 그쪽 업로드 경로도 같은 증상인지 확인이 필요합니다.

   고칠 때 함께 봐야 할 것 — 응답도 안 받고 있다

   요청 DTO 뿐 아니라 응답 DTO 도 contentLength/maxContentLength 를 버립니다.

   // ReceiverAuthDto.kt:57  ReceiverAuthPresignedUrlDto
   presignedUrl · fileKey · fileUrl · contentType   // contentLength 없음

   BE 응답 스키마(PresignedUrlResponse)는 "PUT 요청 시 필수인 Content-Length 값(바이트). 요청한 contentLength 와 동일" 을 내려줍니다. 따라서 수정은 두 곳입니다.

   1. ReceiverAuthPresignedUrlRequestDto 에 contentLength: Long 추가 + 호출부에서 실제 파일 바이트 크기 전달
   2. ReceiverAuthPresignedUrlDto 에 contentLength 를 받아, S3 PUT 시 Content-Length 헤더를 그 서명값과 일치시키기 (헤더가 어긋나면 presigned 서명 검증에서 다시 실패)

   curl 대조로 확인 — presigned 에 contentLength 를 넣고 S3 PUT 의 Content-Length 를 맞추면 200 → PUT 200 → delivery-verification 200 으로 전 구간이 열립니다(이 경로로 만든 PENDING 건을 admin 으로 승인까지 태워 확인).
3. OnlyReadOneBook

   added a commit that references this issue on Aug 25, 2026

   docs(qa): 수신자 열람 흐름 규명 — admin 승인으로 뒷부분까지 검증

   ...

   960044a
4. OnlyReadOneBook

   closed this as completedin #1287on Aug 28, 2026