-
Notifications
You must be signed in to change notification settings - Fork 20
Scopes are not filtered on search-type #83
Comments
Hey @liquid36, thanks for catching this! I've added it to our team's backlog. |
We are also experiencing this bug with user/ scopes. It allows a user access to ANY resource type as long as there is at least one user/ resource in the scope list. Example: A scope list with user/Procedure.read allows access to read Observations |
Hi @medhost-bfindeisen , thank you for bringing this to our attention, -Fernando |
@medhost-bfindeisen is this specifically for |
@rsmayda , this appears specific to search-type, read would result in the last condition here to be false: |
@medhost-bfindeisen we weren't able to replicate with the |
Hi @rsmayda Our scp only has access to Procedure.read:
Our request is for an Observation: This observation is returned. If we change the request to be a read: We were expecting the search to also return a 401 due to the Observation not being in the scope list. Our fhiruser claim is the path to our practitioner resource. |
@medhost-bfindeisen just published to NPM let us know if this helps! The version is v3.1.2 |
@medhost-bfindeisen we just published version 3.1.3 see above PR for more context |
I just upgrade the package version on my project and i can confirm that the issues was resolved. Thanks! |
The issue is resolved for system, patient, and user scopes. Thanks! |
That's great to hear! I'll go ahead and close this issue for now, but feel free to reopen if there's anything else. |
Hi! I'm having an issue in this lines which changes on this #79
fhir-works-on-aws-authz-smart/src/smartScopeHelper.ts
Line 58 in 93df88f
This is my use case:
If the user claims for this scope
system/DocumentReference.read system/Patient.read
but ask for a Procedure resource, thefilterOutUnusableScope
mark both scope as usable and then the operation is allowed.The text was updated successfully, but these errors were encountered: