fix: removing insertion of users groups into header which causes status 431 Request Header Fields Too Large error when user belongs to too many groups

Type of change

  • Bug Fix
  • Feature

Fix for issue: #103

Does this introduce a change in the core logic?

Yes

Does this introduce a change in the cloud provider implementation, if so which cloud?

  • AWS
  • Azure
  • Google Cloud
  • IBM

Does this introduce a breaking change?

No

What is the current behavior?

Currently, if a user belongs to many data groups, requests to Policy service fail with a status 431 Request Header Fields Too Large error.

What is the new/expected behavior?

Have you added/updated Unit Tests and Integration Tests?

Yes - only unit tests.

Rationale

This seems to be a known issue as it is documented in both Azure's and Policy integration documentation. However, I do not understand why headers are being added/mutated at all; Policy service reads the user groups from the request body in the request body: https://community.opengroup.org/osdu/platform/system/search-service/-/blob/master/search-core/src/main/java/org/opengroup/osdu/search/policy/service/PolicyServiceImpl.java?ref_type=heads#L52, which by itself is unnecessary since Policy service makes it's own request to Entitlements to check user authorization. Regardless, it appears that the original implementation is using this as a bad practice of using the headers as request context or there was some other use case for these headers long ago and are no longer in use.

The root cause of the issue is the X-Data-Group header but I have removed the other headers as well (X-AppEngine-Cron, X-Data-Root-User) as I cannot see other usages of these headers. The X-AppEngine-Cron header is used to check the path is cron-handlers, which also seems to be a non-existent service.

Edited by Marc Burnie [AWS]

Merge request reports

Loading