Skip to content

πŸ§ͺ Auto-PR: Merge develop β†’ test - #1023

Merged
proxy-smart-releaser[bot] merged 3 commits into
testfrom
develop
Aug 14, 2026
Merged

πŸ§ͺ Auto-PR: Merge develop β†’ test#1023
proxy-smart-releaser[bot] merged 3 commits into
testfrom
develop

Conversation

@proxy-smart-releaser

Copy link
Copy Markdown
Contributor

Automated Pull Request πŸ€–

Commits ahead of test: 2
Commits behind test: 0
TODOs remaining in codebase: 3

quotentiroler and others added 3 commits August 14, 2026 19:58
Two independent faults, both fatal to exactly the audience a system-scoped
FHIR API has, and both invisible on beta because beta runs behind Caddy
with no WAF.

The WAF blocked every request with no User-Agent header. Server-side HTTP
clients do not send one unless told to β€” Cloudflare Workers' fetch is one,
anything on undici defaults is another. Measured on production: the same
URL answers 200 with `-A curl/8.0` and 403 with `-A ""`, for both
.well-known/smart-configuration and /metadata. So SMART discovery failed
for every conformant headless client. NoUserAgent_HEADER joins the
excluded sub-rules, which sets it to COUNT: it still evaluates and still
reports, it just stops terminating the request. A bot heuristic that
blocks machine clients is wrong for this API specifically.

The CapabilityStatement advertised no OAuth endpoints. HAPI does not know
it sits behind a SMART authorization layer, so it returns rest[].security
empty, and /metadata was passed through with URL rewriting only. We are
that layer, so withSmartSecurity adds the oauth-uris extension and the
SMART-on-FHIR service coding from the same service that builds
.well-known/smart-configuration β€” the two documents cannot disagree. A
server that already declares its own endpoints keeps them, a body that is
not a CapabilityStatement is passed through untouched, and a discovery
failure serves the upstream document rather than an error.

Found from the other side: maxhealth.tech's provisioning job reported
"Failed to discover SMART endpoints" on every run and a member's record
went unwritten, while curl against the same URL returned 200.
…mint

The completeness fix in 9c9b19b could not reach a single link already in
circulation, and this is why: encryptSHLFile runs at mint, the ciphertext is
stored on the session, and the manifest endpoint replays it verbatim
(`embedded: entry.jwe`). Whatever the document claimed on the day it was created,
it claims forever. A link minted before that fix still tells its recipient

  Complete summary β€” the patient shared their full health record

over a view where the proxy denies all but Patient, ImagingStudy and metadata.

Nothing required the snapshot: the session already holds studyInstanceUID,
shareScope, patientId, sessionToken, expiresAt and the SHL key, so the manifest
can state what is true when asked. It now rebuilds and re-encrypts the document
on each fetch, falling back to the stored blob only if encryption fails β€” a stale
claim still beats handing the recipient a link that will not open.

Mint and manifest share one buildSmartApiAccess so a fresh link and a later fetch
cannot disagree. `expires_in` is now counted from the request rather than from
mint, where it had been describing a lifetime that started days ago.

Existing links, including the one that prompted this, are corrected as soon as the
backend deploys. No re-share needed.
@proxy-smart-releaser
proxy-smart-releaser Bot merged commit 3bd0951 into test Aug 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant