ReSSO v0.9.76
로그인 화면이 이쪽 장애를 "로그인 요청이 만료되었다"고 답했습니다. RP에서 넘어온 로그인 화면은 폼을 그리기 전에 GET /api/v1/auth/challenge/{token}으로 park된 인가 요청을 먼저 읽는데, 그 읽기의 모든 실패에 한 문장으로 답했습니다 — "로그인 요청이 만료되었습니다. 연결한 서비스에서 다시 시작하세요." 그 답이 맞는 경우는 하나뿐입니다. 서비스는 소진·만료·발급된 적 없는 request token에만 404를 답하고, 그것만이 토큰에 관한 사실입니다. 저장소가 답하지 않으면 500이고, 페이지가 재시작 중에 fetch하면 응답 자체가 없습니다 — 그 둘은 이쪽 문제이고, 사람이 들고 있는 요청은 소진되지 않은 채 그대로 남아 있습니다. 그래서 그 한 문장은 설명이 아니라 지시였고, 되는 쪽에서 사람을 떼어놓았습니다: RP로 돌아가 새 request token을 받고, 여기 도착해 같은 장애를 다시 만납니다.
수정
- 이제 404만 옛 문구를 유지합니다. 그 경우에만 연결한 서비스에서 다시 시작하는 것이 유일한 출구이기 때문입니다.
- 나머지 실패는 "요청은 그대로 남아 있으니 연결한 서비스에서 다시 시작하지 말고, 잠시 후 다시 시도하세요"로 답합니다. 같은 challenge를 다시 부르는
다시 시도버튼과, 문의 전화에 쓸 Trace ID가 함께 나옵니다. - 그 Alert이 이 화면의 마지막 말이었습니다 — 누를 것이 없고
challenge.isError가 폼을 계속 막으므로, 장애가 걷힌 뒤에도 화면은 글자 그대로 같아 보였습니다. 이제다시 시도가 성공하면 같은 요청으로 그 자리에서 흐름이 이어집니다. - 근거는 한 디렉터리 옆에 이미 있었습니다. 콘솔의
ErrorAlert(components/Feedback.tsx)는 status 0·429·5xx에만 재시도를 내주고 나머지에는 내주지 않으며, 각 상태에 무엇을 할지까지 적어 줍니다. 로그인하지 않은 사람이 보는 유일한 화면만 그 구분을 버리고 있었습니다. - 백엔드는 손대지 않았습니다. 이 구분은
writeStoreError가 이미 하고 있었습니다 — 404와 500을 나누는 판단은 서버에 있었고, 그것을 버린 것은 화면이었습니다. - 새 테스트 둘이 지킵니다: 소진된 토큰(404)은 여전히 RP로 돌려보내고 재시도 버튼을 내주지 않는 것과, 500은 다른 문구와 Trace ID를 보이고 만료 문구를 보이지 않으며, 재시도 뒤 Client 안내가 뜨고 폼이 다시 쓸 수 있게 되는 것. 두 번째가 수정 전 페이지에서 실제로 실패하는 것을 확인했습니다.
docs/operations.md에 두 문구를 원인과 사용자가 할 일로 나눠 읽는 표와 **"두 번째 문구가 보고되면 사용자를 RP로 돌려보내지 마세요"**를 적었습니다.
Upgrade notes
동작이 달라지는 곳은 로그인 화면 하나입니다: 인가 요청을 읽지 못한 이유가 404가 아닐 때 문구가 바뀌고 다시 시도 버튼과 Trace ID가 생깁니다. 정상 동작에서도, 소진된 request token에서도 아무것도 달라지지 않습니다 — 404의 문구는 전과 같습니다. API도, 상태 코드도, 저장되는 데이터도 그대로이고 마이그레이션도 설정 변경도 없습니다. 지원 창구에는 두 문구가 서로 다른 일을 뜻한다는 것만 알리시면 됩니다(docs/operations.md의 표) — 두 번째 문구는 이쪽 장애이므로 사용자를 RP로 돌려보내지 말고 그 자리에서 다시 시도하게 하세요. 되돌릴 때 이전 이미지도 그대로 동작합니다.
Docker image: resso:v0.9.76
Archive: resso-v0.9.76.tar.gz
SHA-256: 803f96b3d243530397c6eb0c295cb63f590ebe745e96928bf70a6675efbf0124