Describe the bug
fhir-smart does appear to enforce JSONPatch and FHIRPathPatch requests. When using a JWT with ff94628809f34970a7a8199bccf2f23c as one of the patient_ids and a "patient/*.read" scope the following happens:
This PUT request gives a 403 as expected:
curl 'http://localhost:9080/fhir-server/api/v4/Patient/ff94628809f34970a7a8199bccf2f23c' -H "Authorization: Bearer $bearer" -H 'Content-Type: application/json' -d '{"resourceType": "Patient", "id": "ff94628809f34970a7a8199bccf2f23c", "gender":"female"}' -X PUT
However, if I do what is essentially the same request using JSONPatch, the change is allowed:
curl 'http://localhost:9080/fhir-server/api/v4/Patient/ff94628809f34970a7a8199bccf2f23c' -H "Authorization: Bearer $bearer" -H 'Content-Type: application/json-patch+json' -d '[{ "op": "add", "path": "/gender", "value": "female" }]' -X PATCH
With FHIRPathPatch the same can be observed.
I initially suspected that it was because org.linuxforhealth.fhir.smart.AuthzPolicyEnforcementPersistenceInterceptor does not have a beforePatch method, but after adding this method (with the same implementation as beforeUpdate) the problem persisted.
Am I missing something, or is this a bug in fhir-smart?
Environment
I'm currently still using 4.11.1. Looking through the changelogs and relevant code I don't believe this has already been fixed in the newer versions.
To Reproduce
Steps to reproduce the behavior:
- Have a JWT with read-only access to a patient (I'm using
"patient/*.read")
- Perform a JSONPatch or FHIRPathPatch request for data belonging to the current patient.
- The request will succeed.
Expected behavior
The request should not succeed unless the JWT has a write scope for the resource.
Describe the bug
fhir-smartdoes appear to enforce JSONPatch and FHIRPathPatch requests. When using a JWT withff94628809f34970a7a8199bccf2f23cas one of thepatient_ids and a"patient/*.read"scope the following happens:This PUT request gives a 403 as expected:
However, if I do what is essentially the same request using JSONPatch, the change is allowed:
With FHIRPathPatch the same can be observed.
I initially suspected that it was because
org.linuxforhealth.fhir.smart.AuthzPolicyEnforcementPersistenceInterceptordoes not have abeforePatchmethod, but after adding this method (with the same implementation asbeforeUpdate) the problem persisted.Am I missing something, or is this a bug in
fhir-smart?Environment
I'm currently still using 4.11.1. Looking through the changelogs and relevant code I don't believe this has already been fixed in the newer versions.
To Reproduce
Steps to reproduce the behavior:
"patient/*.read")Expected behavior
The request should not succeed unless the JWT has a write scope for the resource.