From a1a50ad2577a711678d3a5076e163892b4b09798 Mon Sep 17 00:00:00 2001 From: Jafer Khan Date: Sat, 14 Dec 2019 18:55:49 +0500 Subject: [PATCH] Fixed typo in docs --- .../ca/uhn/hapi/fhir/docs/security/authorization_interceptor.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/security/authorization_interceptor.md b/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/security/authorization_interceptor.md index 8a84a8d7f7d..54b507aaf81 100644 --- a/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/security/authorization_interceptor.md +++ b/hapi-fhir-docs/src/main/resources/ca/uhn/hapi/fhir/docs/security/authorization_interceptor.md @@ -27,7 +27,7 @@ The AuthorizationInterceptor works by examining the client request in order to d When authorizing a read operation, the AuthorizationInterceptor always allows client code to execute and generate a response. It then examines the response that would be returned before actually returning it to the client, and if rules do not permit that data to be shown to the client the interceptor aborts the request. -Note that there are performance implications to this mechanism, since an unauthorized user can still cause the server to fetch data even if they won't get to see it. This mechanism should be comprehensive however, since it will prevent clients from using various features in FHIR (e.g. _include or _revinclude) to "trick" the server into showing them date they shouldn't be allowed to see. +Note that there are performance implications to this mechanism, since an unauthorized user can still cause the server to fetch data even if they won't get to see it. This mechanism should be comprehensive however, since it will prevent clients from using various features in FHIR (e.g. _include or _revinclude) to "trick" the server into showing them data they shouldn't be allowed to see. See the following diagram for an example of how this works.