entitlements-gcp issueshttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements-gcp/-/issues2021-06-16T22:17:23Zhttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements-gcp/-/issues/1CI/CD Pipeline2021-06-16T22:17:23Zethiraj krishnamanaiduCI/CD Pipelinewe will have to set up a full CI/CD Pipeline for GCP entitlements service. GCP Entitlements developed in Golang so the default pipeline might not work.we will have to set up a full CI/CD Pipeline for GCP entitlements service. GCP Entitlements developed in Golang so the default pipeline might not work.Release 2.0David Diederichd.diederich@opengroup.orgethiraj krishnamanaiduDavid Diederichd.diederich@opengroup.orghttps://community.opengroup.org/osdu/platform/security-and-compliance/entitlements-gcp/-/issues/2Bug: Entitlement GET /groups API returns 200 for Expired Authorization Token2021-06-16T22:17:22ZHong YanBug: Entitlement GET /groups API returns 200 for Expired Authorization TokenHi Team,
I am working on storage-gcp service and find probably a bug behavior when it calls the entitlement service.
## Target Request
```
curl --location --request GET 'https://entitlements-dot-opendes.appspot.com/entitlements/v1/gro...Hi Team,
I am working on storage-gcp service and find probably a bug behavior when it calls the entitlement service.
## Target Request
```
curl --location --request GET 'https://entitlements-dot-opendes.appspot.com/entitlements/v1/groups' \
--header 'data-partition-id: common' \
--header 'Authorization: ${token}'
```
Here ${token} is an **expired** Google Oauth Bearer token
## Expected Behavior
```
{
"code": 401,
"reason": "Access denied",
"message": "The user is not authorized to perform this action"
}
```
## Actual Behavior
```
{
"code": 200,
"reason": "Access denied",
"message": "The user is not authorized to perform this action"
}
```
This response also returns an HTML body which displays
![image](/uploads/e34f0d619857a852a53c8247bfa4c4d3/image.png)
This status code causes confusion because storage service only checks if the response has success code but does not look into the body. In this case it assumes the response succeeded and tries to parse the body. When it fails to parse the body it will throw an exception and simply put the status code into it, which is also 200. As a result, storage service (And other services as well I guess) will throw 200 Access denied in the same way.
This bug only happened with **expired** token. If you provide a valid token or a token with wrong format it will properly returns 401.