-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fhir-smart not enforced for JSONPatch and FHIRPathPatch #4101
Comments
lmsurpre
added a commit
that referenced
this issue
Nov 30, 2022
and add corresponding tests to AuthzPolicyEnforcementTest.java Signed-off-by: Lee Surprenant <lmsurpre@merative.com>
lmsurpre
added a commit
that referenced
this issue
Nov 30, 2022
…pdate is skippable Previously, a skippable update (one that would not affect the contents of the resource being updated) would result in a success without invoking beforeUpdate or beforePatch interceptor methods. For users of fhir-smart, this behavior is confusing because the user may not have write access to this resource type, but the server is "allowing" the write anyway (even though its being optimized away). Signed-off-by: Lee Surprenant <lmsurpre@merative.com>
lmsurpre
added a commit
that referenced
this issue
Nov 30, 2022
…pdate is skippable Previously, a skippable update (one that would not affect the contents of the resource being updated) would result in a success without invoking beforeUpdate or beforePatch interceptor methods. For users of fhir-smart, this behavior is confusing because the user may not have write access to this resource type, but the server is "allowing" the write anyway (even though its being optimized away). Signed-off-by: Lee Surprenant <lmsurpre@merative.com>
lmsurpre
added a commit
that referenced
this issue
Dec 9, 2022
* issue #4101 - handle patch in fhir-smart interceptor and add corresponding tests to AuthzPolicyEnforcementTest.java Signed-off-by: Lee Surprenant <lmsurpre@merative.com> * updated comment as suggested Signed-off-by: Lee Surprenant <lmsurpre@merative.com> * add clarifying comments as requested in review Signed-off-by: Lee Surprenant <lmsurpre@merative.com> Signed-off-by: Lee Surprenant <lmsurpre@merative.com>
lmsurpre
added a commit
that referenced
this issue
Dec 9, 2022
…pdate is skippable Previously, a skippable update (one that would not affect the contents of the resource being updated) would result in a success without invoking beforeUpdate or beforePatch interceptor methods. For users of fhir-smart, this behavior is confusing because the user may not have write access to this resource type, but the server is "allowing" the write anyway (even though its being optimized away). Signed-off-by: Lee Surprenant <lmsurpre@merative.com>
lmsurpre
added a commit
that referenced
this issue
Dec 12, 2022
issue #4101 - call beforeX interceptor methods prior to checking if update is skippable
Generated a token with scope "patient/*.read" for patient_id 1850f9523a4-c7c2cc41-6544-404b-843a-7620eac731d9
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
fhir-smart
does appear to enforce JSONPatch and FHIRPathPatch requests. When using a JWT withff94628809f34970a7a8199bccf2f23c
as one of thepatient_id
s 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.AuthzPolicyEnforcementPersistenceInterceptor
does not have abeforePatch
method, 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.
The text was updated successfully, but these errors were encountered: