You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
When using the Google's Gateway repository, identified a bug related to REST endpoint with the /fhir/* path. If any characters are appended after /fhir/ in a REST endpoint, the WebServlet accepts and begins processing in the access checkers. However, when the actual handleRequest method executes, it fails with an error stating that the FHIR server does not know how to process the request
Steps to Reproduce:
Hit a GET REST endpoint with the path /fhir/*.
Append additional characters to the path (e.g., /fhir/practitioner-details-xyz).
Observe the behaviour that it passes through the access checker.
Expected Behavior:
The system should handle requests with additional characters after /fhir/* gracefully, or there should be a proper validation step at the beginning of execution to check the existence of the resource type.
Actual Behavior:
If you type anything after /fhir/* it returns a response.
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "User is not authorized to GET http://localhost:8080/fhir/practitioner-dewtails?keycloak-uuid=bccd8c41-1c39-400f-b8f4-2172709a7aaa"
}
]
}
Proposed Solution:
I suggest adding a check at the beginning of the execution to validate whether the resource type exists whenever /fhir/* endpoint is triggered.
Description:
When using the Google's Gateway repository, identified a bug related to REST endpoint with the /fhir/* path. If any characters are appended after /fhir/ in a REST endpoint, the WebServlet accepts and begins processing in the access checkers. However, when the actual handleRequest method executes, it fails with an error stating that the FHIR server does not know how to process the request
Steps to Reproduce:
Hit a GET REST endpoint with the path /fhir/*.
Append additional characters to the path (e.g., /fhir/practitioner-details-xyz).
Observe the behaviour that it passes through the access checker.
Expected Behavior:
The system should handle requests with additional characters after /fhir/* gracefully, or there should be a proper validation step at the beginning of execution to check the existence of the resource type.
Actual Behavior:
If you type anything after /fhir/* it returns a response.
Proposed Solution:
I suggest adding a check at the beginning of the execution to validate whether the resource type exists whenever /fhir/* endpoint is triggered.
cc: @ndegwamartin @dubdabasoduba @f-odhiambo
The text was updated successfully, but these errors were encountered: