fix: remediate Sentry errors — scanner blocking, daily stats key, contact form validation, mail failure handling

[bluebamus]

docs/error의 Sentry 이슈 5건을 docs/ai-docs의 기획·설계·작업 계획서에 따라 구현했다.

계획서 Phase 1~5의 코드 작업이 끝났다. Phase 0(nginx)과 SendGrid 계정 점검은 이 저장소 밖의 운영 작업이다.

테스트: 123 passed / 1 skipped (기준선 9 passed / 1 skipped). skip 1건은 이 작업과 무관한 기존 항목이다.
dev · test · stage · prod 네 설정 모두 manage.py check 오류가 없다.

Sentry 이슈별 처리

이슈	원인	처리
ConnectionHardwareStats/MethodStats.MultipleObjectsReturned	일자 유니크 키 없이 get_or_create(created_at__date=…). 생성 시 조회 조건을 컬럼에 반영할 수 없어 중복 row가 쌓이고, 한 번 생기면 이후 모든 요청이 실패	stat_date 유니크 집계키 + UPDATE→INSERT→UPDATE
DataError value too long for varchar(16)	뷰가 request.POST를 직접 읽고 저장 전 검증 없음	GetInTouchForm이 저장 전에 거부
HTTP 401 / Maximum credits exceeded	외부 메일 벤더 상태. 스레드 발송이라 뷰가 실패를 알 수 없었음	접수(state)와 발송(status) 분리. 401 자체의 원인은 운영 점검 필요

주요 변경

• BlockSuspiciousPathMiddleware — SecurityMiddleware 직후, 통계 미들웨어 앞에서 .php/wp-*/.env 경로를 본문 없는 404로 조기 차단. nginx의 대체물이 아니라 fallback이다.
• 통계 집계키 교체 — UPDATE 한 문장이 원자적이라 select_for_update 없이 동작하고, DB 유니크 제약이 중복을 최종적으로 막는다.
• dedupe_connection_stats — 날짜별 합산 병합 + stat_date backfill. --dry-run 지원, 멱등.
• GetInTouchForm — 입력 정책을 한곳에 모아 모델 컬럼 제약과 일치시켰다. 도달 불가능한 저장 코드 6블록 제거. DNS 타임아웃은 '검증 불가'로 보고 통과시키고 MX 부재만 거부한다.
• send_mail_sync() + GetInTouchLog.status — 문의를 먼저 저장한 뒤 발송하므로 벤더 장애로 문의가 유실되지 않는다. 실패 시 "접수 완료, 발송 지연"으로 안내. 로그의 수신자 주소는 마스킹.
• reCAPTCHA — CONTACT_FORM_CAPTCHA로 제어, 기본 False, prod/stage만 활성.
• Sentry before_send — Http404/DisallowedHost/SuspiciousOperation과 스캐너 URL 이벤트를 버린다.

계획 외 발견 사항

커스텀 에러 페이지가 전부 HTTP 200을 반환하고 있었다. 400/403/404/500 핸들러가 status_code를 설정한 응답을 버리고 render()의 새 응답(기본 200)을 반환했다. 존재하지 않는 URL이 200으로 응답하면 스캐너에게는 모든 경로가 유효해 보인다. 기존 테스트는 본문 문자열만 검사해 놓치고 있었다.

prod 설정이 manage.py check에서 실패하고 있었다. staticfiles.E002. 체크는 모든 관리 명령 앞에서 실행되므로 prod 설정으로는 migrate도 정리 명령도 돌릴 수 없었다. stage.py가 이미 같은 이유로 처리해 둔 형태에 맞췄다.

마이그레이션 동작 2건 확인. 통계 마이그레이션은 Meta.app_label 때문에 home/migrations/에 생성된다. 그리고 migrations/ 디렉터리가 없는 상태에서 인자 없는 makemigrations는 프로젝트 앱에 아무것도 만들지 않으므로 최초 1회는 앱 이름을 명시해야 한다.

검증

실제 운영 업그레이드 순서를 재현했다 — 변경 전 모델로 레거시 스키마 생성 → 같은 날짜 중복 row 심기 → migrate → dedupe_connection_stats.

• 중복 row가 있는 상태에서 마이그레이션이 오류 없이 적용됐다
• 날짜별 1 row로 병합되고 카운트가 정확히 합산됐다 (2026-08-05: win 10+7 = 17)
• DB 유니크 제약이 실제로 동작한다
• 명령을 두 번 돌려도 결과가 같다

머지 후 운영 작업

순서를 지켜야 한다. 상세 절차는 docs/ai-docs/reports/06-implementation-report.md에 있다.

1. 운영 DB 백업 — 정리 명령이 row를 삭제한다
2. nginx 차단 location 적용 (docs/ai-docs/security/02-nginx-php-scan-blocking.md)
3. makemigrations home portfolio → migrate
4. dedupe_connection_stats --dry-run → dedupe_connection_stats
5. SendGrid API key · sender 인증 · 크레딧 점검
6. RECAPTCHA_PUBLIC_KEY / RECAPTCHA_PRIVATE_KEY에 실제 키 설정 (테스트 키면 check가 실패한다)

알려진 트레이드오프

문의 폼 메일이 동기 발송이라 발송 결과를 정확히 알 수 있는 대신, 벤더 응답이 느리면 요청이 길어진다. SendGrid 백엔드는 EMAIL_TIMEOUT을 따르지 않는다. status에 queued를 미리 정의해 두었으므로 Celery 이관은 바로 가능하다.

🤖 Generated with Claude Code