search

IHTSDO / authoring-acceptance-gateway

Microservice to ensure service acceptance criteria are met before content promotion within the SNOMED CT Authoring Platform.
Other
0 stars 1 forks source link

Null Point Exception in snowstormRestClientFactory.getClient() #21

Open tandara0 opened 1 year ago

tandara0 commented 1 year ago

I tried to install and use authoring acceptance gateway. I sent a API and get "Internal Server Error", which because of the Null Point Exception in snowstormRestClientFactory.getClient().

But the snowstorm.url is correct. We found the authoring acceptance gateway's test log as below:

2023-05-17 07:05:52.033 INFO 1 --- [ main] o.snomed.aag.SnowstormConnectionTester : Confirming connection to Snowstorm. (Snowstorm URL: http://172.30.1.60:8071/version) 2023-05-17 07:05:52.070 INFO 1 --- [ main] o.snomed.aag.SnowstormConnectionTester : Successfully confirmed connection to Snowstorm.

But, I sent GET API, such as: http://localhost:8090/authoring-acceptance-gateway/acceptance/MAIN/SAP2/SAP2-3?matchAuthorFlags=true

The Null Point Exception log was as below:

2023-05-17 07:05:59.652 ERROR 1 --- [nio-8090-exec-1] o.a.c.c.C.[.[.[.[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [/authoring-acceptance-gateway] threw exception [Request processing failed; nested exception is java.lang.NullPointerException] with root cause java.lang.NullPointerException: null at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:878) ~[guava-29.0-jre.jar!/:na] at com.google.common.cache.LocalCache.getIfPresent(LocalCache.java:3955) ~[guava-29.0-jre.jar!/:na] at com.google.common.cache.LocalCache$LocalManualCache.getIfPresent(LocalCache.java:4865) ~[guava-29.0-jre.jar!/:na] at org.ihtsdo.otf.rest.client.terminologyserver.SnowstormRestClientFactory.getClient(SnowstormRestClientFactory.java:33) ~[otf-common-4.3.0.jar!/:na] at org.snomed.aag.data.services.BranchSecurityService.getBranchOrThrow(BranchSecurityService.java:65) ~[classes!/:1.6.2-SNAPSHOT] ......................

kaicode commented 1 year ago

The AAG has been designed to run behind a layer of authentication. Then within the AAG application factory service creates a snowstorm client with the users authentication and roles to act as them.

When a request is made to AAG first Nginx receives the request. Nginx then authenticates the request by calling the Identity Management Service. If authenticated then the authentication headers are added to the internal HTTP request that is forwarded to the actual AAG java application. These headers are X-AUTH-username, X-AUTH-roles and X-AUTH-token.

In its current state I don't think the AAG service can not work without this security layer. You could consider not including the AAG in your deployment.