You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Show an error when a #verify?vc= link can't load its credential #272
When a #verify?vc=<url> link can't load its credential, VerifierPlus shows the home page with no error. For example, this happens after the holder clicks Unshare in the LCW web wallet and wallet storage starts returning 404.
The person who opened the link can't tell whether the link is broken, the credential was unshared, or the page is still loading.
Short links (#271) redirect to the same #verify?vc= page, so they have the same problem.
Where
app/page.tsx:
On first load (about lines 84-101), getJSONFromURL returns "" when /api/proxy fails, and nothing is shown.
handlePopstate (about lines 61-69) has the same gap.
Expected
If the credential can't be fetched, show an error that explains the likely reasons, like the stored-credential page already does (app/components/LoadingError/LoadingError.tsx): the link may be wrong, or the holder may have unshared it or let it expire.
Acceptance criteria
Opening /#verify?vc=<url> where the URL returns 404 shows an error instead of the home page.
Opening a short link whose credential was unshared shows the same error.
Links that work still open the credential as before.
Related, found while reviewing #271: app/page.tsx decodes the vc value twice (URLSearchParams.get already decodes, then decodeURIComponent runs again at about lines 64 and 87). A credential URL that contains escapes like %2F or %25 gets changed before it is fetched, and a lone % throws a URIError. This affects long links and short links the same way. Dropping the extra decodeURIComponent should fix it, since /#verify?vc= links are either unencoded (from LCW) or encoded once (app/page.tsx:299).
The LCW web wallet now hits this every time a learner takes a link down. The rebuilt share dialog (digitalcredentials/lcw-front-end#155) has "Only you → Take it down", which removes the public copy, so the storage returns 404 pws#not-found (checked on lcw-sandbox.org on 22 October). Anyone who opens the old #verify?vc= link, or scans its QR code, lands on the VerifierPlus home page with no explanation.
The /credentials/<id> route already handles this well: #34 built the not-found page and #121 (PR #153) reworded it. Reusing that page or its wording for #verify?vc= would make both kinds of link behave the same.
Discussed with James and Kerri on 22 October, who agreed this belongs in VerifierPlus.
Activity
threeqube commentedon Oct 22, 2026
Related, found while reviewing #271:
app/page.tsxdecodes thevcvalue twice (URLSearchParams.getalready decodes, thendecodeURIComponentruns again at about lines 64 and 87). A credential URL that contains escapes like%2For%25gets changed before it is fetched, and a lone%throws aURIError. This affects long links and short links the same way. Dropping the extradecodeURIComponentshould fix it, since/#verify?vc=links are either unencoded (from LCW) or encoded once (app/page.tsx:299).threeqube commentedon Oct 23, 2026
The LCW web wallet now hits this every time a learner takes a link down. The rebuilt share dialog (digitalcredentials/lcw-front-end#155) has "Only you → Take it down", which removes the public copy, so the storage returns
404 pws#not-found(checked on lcw-sandbox.org on 22 October). Anyone who opens the old#verify?vc=link, or scans its QR code, lands on the VerifierPlus home page with no explanation.The
/credentials/<id>route already handles this well: #34 built the not-found page and #121 (PR #153) reworded it. Reusing that page or its wording for#verify?vc=would make both kinds of link behave the same.Discussed with James and Kerri on 22 October, who agreed this belongs in VerifierPlus.