ReSSO v0.9.75
인증 없는 누구든 쿼리 파라미터 하나로 멀쩡한 데이터베이스에 대한 경보를 울릴 수 있었습니다. max_age는 호출자가 보내는 숫자인데, 인가 Endpoint는 그것을 그대로 최근 인증 시각 쿼리로 넘겼고 그 쿼리는 데이터베이스에게 그 숫자로 interval을 만들라고 합니다. interval이 담을 수 있는 한계(약 9.2e12초)를 넘는 값은 거기서 실패하며, 그 실패는 저장소가 멈춘 것과 구별되지 않습니다 — 요청은 302 error=server_error로 나가고 바로 앞 릴리즈가 더한 resso_authorization_errors_total{stage="auth_time"}을 올렸습니다. 운영자가 장애로 읽으라고 문서에 적혀 있는 바로 그 계열입니다. 그것을 받은 사람은 sso_sessions를 들여다보러 갔습니다.
수정
- 이제 그런 값은 거절하지 않고 clamp합니다. 상한은
MaxInt32(2147483647초, 약 68년)입니다. - clamp는 아무것도 잃지 않습니다. SSO Session의 수명은
session_ttl_seconds가 상한이고 그 값은 30일로 제한되므로, 그보다 큰max_age는 존재하는 어떤 Session이든 충족합니다. 답은 처음부터 정해져 있었고 계산만 되지 않았을 뿐입니다. 상한은 그 두 값이 같아지는 지점보다 60년 더 뒤입니다. - int64에도 담기지 않는 값은 거절하지 않고 같은 상한에 도달하게 했습니다. 그저 거대한 값은 clamp하면서 더 거대한 값만 거절하면 사양에 없는 선을 긋는 것이기 때문입니다.
ParseInt가 범위 초과를 알려주며 포화시키므로 두 형태가 같은 자리로 모입니다. - 숫자가 아닌 값과 음수는 그대로
invalid_request입니다 — 그것들은 호출자에 관한 사실이고, 전과 달라지지 않습니다. auth_time단계 자체는 핸들러에 남습니다 — 두 조회 사이에 세션이 사라지는 경우와 저장소 자체의 실패가 여전히 그 자리를 씁니다. 다만 연동 테스트의 행은 잃었습니다: 그 쿼리가 읽는 테이블은 모두 앞의 세션 조회가 먼저 읽으므로 거대한max_age가 그 단계에 닿는 유일한 길이었고, 이번 수정이 지운 것이 정확히 그 길입니다.- 대신 그 거대한
max_age를 테스트가 올바로 답하는 요청 쪽으로 옮겨, 코드가 나가는 것과 실패 계열을 건드리지 않는 것을 함께 고정했습니다.TestIntegrationMaxAgeForcesReauthentication이 clamp되는 두 형태(interval 한계를 넘는 값, int64를 넘는 값)와 여전히 거절되는 음수를 지킵니다. 새 단언 셋이 수정 전 코드에서 모두 실제로 실패하는 것을 확인했습니다. docs/compatibility.md의max_age행에 clamp를,docs/operations.md의resso_authorization_errors_total항목에 **"이제 여섯 값 모두 이쪽 장애만 센다"**를 적었습니다.
Upgrade notes
동작이 달라집니다: max_age가 약 9.2e12초를 넘는 인가 요청이 302 error=server_error 대신 정상적으로 처리됩니다(그런 값은 어떤 Session이든 충족하므로 재인증 없이 코드가 나갑니다). 정상 동작에서는 아무것도 달라지지 않습니다 — 현실적인 max_age도, 숫자가 아닌 값과 음수의 invalid_request도 전과 같습니다. resso_authorization_errors_total{stage="auth_time"}이 v0.9.74에서 올라간 기록이 있다면 저장소 장애가 아니라 이 파라미터였을 수 있으므로 그 시각의 요청을 함께 보시면 됩니다. 마이그레이션도, 설정 변경도, 저장되는 데이터의 변화도 없고 되돌릴 때 이전 이미지도 그대로 동작합니다.
Docker image: resso:v0.9.75
Archive: resso-v0.9.75.tar.gz
SHA-256: a597755737f3da299e29324b8c4ee664a6b3a5929b1b13739a7ae44a13b20204