Fire Arrow Server 2.6.2
Fire Arrow Server 2.6.2 has been released.
- (security) A valid token on the FHIR base URL with a trailing slash is authenticated instead of treated as the Public role
- (feature) Organizations open on a detail page, including the practitioners who belong to that organization
- (bugfix) Concurrent requests from one caller no longer time out while the server looks up that identity
A Trailing Slash Ignored the Caller's Token
A request that carries a Bearer token is supposed to run as that caller. Posting a transaction to the FHIR base URL is a normal way to submit a batch.
Until 2.6.2, the base URL with a trailing slash did not read the token. With the API served at /fhir, POST /fhir/ carrying a valid Bearer token — a JWT or an API token — ran as the Public role. A write was then usually rejected with 403 Forbidden, because Public has no create, update, or delete rules. The same request without the slash (POST /fhir) authenticated and applied the caller's rules. A call to the CDS Hooks base URL with a trailing slash (POST /cds-services/) had the same gap. Paths under the API, such as /fhir/Patient/..., were already authenticated.
Where the Public role is allowed to read or write, that request was authorized under Public rules. The caller's own rules were not applied.
Request, with the API at /fhir | Until 2.6.2 | Starting with 2.6.2 |
|---|---|---|
POST /fhir with a valid token | Caller's identity | Caller's identity |
POST /fhir/ with a valid token | Public role, usually 403 Forbidden | Caller's identity |
POST /cds-services/ with a valid token | Public role | Caller's identity |
| A Bearer token that fails validation | Public role | Public role |
| No token | Public role | Public role |
Starting with 2.6.2, both forms of the base URL read the token and resolve the caller. A transaction posted to /fhir/ uses the same identity as one posted to /fhir.
A Bearer token that is present but fails validation still continues as Public, on every FHIR API request. That failure is now logged as a warning, and counted on authentication.token_validation_failed with tag issuer set to a configured issuer or unknown. A deployment that receives many invalid tokens will see those warnings. No configuration change is required. Deployments that do not authenticate callers are unaffected.
Organization Detail Page
Opening an organization from the administration list opens a detail page for that record. The header shows the name, the parent organization when partOf is set, the Organization id, and whether the record is active. The list is the tree of organizations. Creating one still starts there, and saving it opens this page.
Details is the organization form: name, type, aliases, parent, active flag, phone, email, website, address, and contact persons. Edit and delete are on this tab. Delete asks for confirmation and removes the Organization.
Practitioners lists practitioners who have a PractitionerRole in this organization, with name, email, clinical roles, and dashboard access. Add searches for a practitioner who already exists, by name or email, and requires at least one clinical role or dashboard feature. Edit changes those roles for this organization. Remove asks for confirmation and deletes that practitioner's PractitionerRole resources in this organization. The Practitioner record remains.
The page is available to a user with organization-manager, and to an administrator. No configuration is required.
Bug Fixes
One caller timed out waiting for an identity
After a caller authenticates, the server looks up the identity that token maps to. On a provider with fire-arrow.authentication.providers.<name>.identity-resolution.auto-create-enabled set to true, every request from the same caller waited for the one before it to finish that lookup — including when the identity already existed. A burst that lasted 30 seconds failed the wait. The client received 503 with issue code transient and the message that identity resolution is temporarily unavailable. CarePlan materialization stalled, and other writes from that caller, including Task updates and inbound Communication resources, slowed with it.
Starting with 2.6.2, a caller whose identity already exists is looked up without that wait. Concurrent requests from the same caller proceed together. The first time a caller is seen, the server still creates that identity one request at a time, so two requests cannot create two records for the same caller. A lookup that cannot finish because the database is unavailable still returns 503 and does not continue as Public. A token that matches no identity still continues as Public. Providers that leave auto-create-enabled at its default (false) were not waiting on this lookup.
No configuration change is required.