fix(web): show forbidden/unauthenticated download errors distinctly (BUNYIP-49) #58

Merged

nrupard merged 2 commits from fix/bunyip-49-downloads-forbidden-message into main

2026-06-04 00:30:36 +02:00

nrupard commented

2026-06-03 21:52:52 +02:00

Owner

Problem

The downloads page (bunyip-web dashboard.rs::downloads) rendered every downloads_all error as a single generic message: "Downloads are temporarily unavailable. Refresh the page to try again." But GET /v1/downloads (bunyip-api MemberUser extractor) returns 403 when the caller lacks member access and 401 when the session is rejected. In staging the page showed "temporarily unavailable" while the API was actually returning 401 (GET /v1/users/me -> 401 Unauthorized), so an auth/permissions failure masqueraded as a transient outage and told the user to refresh - which can never fix it.

Fix

ApiError already carries the HTTP status, so branch on it in downloads:

403 -> "Downloads are available with an active membership." + the existing upgrade_link() (-> /membership).
401 -> "Your session has expired. Please sign in again to view downloads."
else (5xx / network / decode) -> the original transient-outage message.

Ok rendering is unchanged. Backend is unchanged - it already returns the correct 401/403; only the frontend's interpretation was wrong.

Note (separate, not fixed here)

The staging 401 means bunyip-web's page guard accepts the BFF session but the forwarded credential is rejected by bunyip-api - a likely token-forwarding/config issue worth its own investigation. This PR only corrects the user-facing message.

Verification

just check-container green: fmt + clippy -D warnings + tests (bunyip-web 7 passed).

#BUNYIP-49

## Problem The downloads page (`bunyip-web` `dashboard.rs::downloads`) rendered every `downloads_all` error as a single generic message: "Downloads are temporarily unavailable. Refresh the page to try again." But `GET /v1/downloads` (bunyip-api `MemberUser` extractor) returns **403** when the caller lacks member access and **401** when the session is rejected. In staging the page showed "temporarily unavailable" while the API was actually returning 401 (`GET /v1/users/me -> 401 Unauthorized`), so an auth/permissions failure masqueraded as a transient outage and told the user to refresh - which can never fix it. ## Fix `ApiError` already carries the HTTP `status`, so branch on it in `downloads`: - **403** -> "Downloads are available with an active membership." + the existing `upgrade_link()` (-> `/membership`). - **401** -> "Your session has expired. Please sign in again to view downloads." - **else** (5xx / network / decode) -> the original transient-outage message. `Ok` rendering is unchanged. Backend is unchanged - it already returns the correct 401/403; only the frontend's interpretation was wrong. ## Note (separate, not fixed here) The staging 401 means bunyip-web's page guard accepts the BFF session but the forwarded credential is rejected by bunyip-api - a likely token-forwarding/config issue worth its own investigation. This PR only corrects the user-facing message. ## Verification `just check-container` green: fmt + clippy -D warnings + tests (bunyip-web 7 passed). #BUNYIP-49

nrupard added 1 commit

2026-06-03 21:52:52 +02:00

fix(web): show forbidden/unauthenticated download errors distinctly (BUNYIP-49)

Check / fmt / clippy / build / test (pull_request) Successful in 1m29s

Details

0d8726e271

The downloads page rendered every `downloads_all` error as "Downloads are temporarily unavailable. Refresh the page to try again." But GET /v1/downloads returns 403 when the caller lacks member access and 401 when the session is rejected (observed in staging: /v1/users/me -> 401), so a permissions/auth failure looked like a transient outage and told the user to refresh when refreshing can never help.

`ApiError` already carries the HTTP `status`, so branch on it in `downloads`:
- 403 -> "Downloads are available with an active membership." plus the existing upgrade_link to /membership.
- 401 -> "Your session has expired. Please sign in again to view downloads."
- everything else -> the original transient-outage message.

Backend is unchanged (it already returns the right 401/403); only the frontend's interpretation is fixed.

just check-container green: fmt + clippy -D warnings + tests (bunyip-web 7 passed).

#BUNYIP-49

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

nrupard added 1 commit

2026-06-03 21:58:01 +02:00

fix(web): handle 404 + add sign-in link on downloads error page (BUNYIP-49 review)

Check / fmt / clippy / build / test (pull_request) Successful in 1m20s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

800261e237

Code review follow-ups: a 404 from /v1/downloads means downloads are disabled server-side (a config state), so it now shows "Downloads aren't available on this server." instead of the transient-outage "refresh" message that can never help - same reasoning that motivated the 401/403 split. The 401 case gains a sign-in link to /login so the user has an actionable next step rather than a dead-end message.

#BUNYIP-49

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>