mod-kb-ebsco-java can not work with the Eureka Keycloak clients due to the absence of the user_id field in x-okapi-token
Description
CSP Request Details
CSP Rejection Details
Potential Workaround
Attachments
blocks
has to be done after
has to be done before
Checklist
hideActivity
Valery_Pilko February 24, 2025 at 10:06 AM
Verified on Eureka Snapshot environment:
User can create/update/delete Knowledge base with valid credentials
eHoldings app is working:
Khalilah Gambrell February 14, 2025 at 1:19 PM
Changed priority because team is unclear why this is a P1.
Vasyl Avramenko February 14, 2025 at 1:00 AMEdited
Hello .
1. I was told by that this operation don’t perform on Eureka Bugfest. They simply don’t need it because already have the following record in the underlying dataset.
The Eureka snapshot, along with the Eureka and OKAPI team environments, lacks the underlying dataset; it only contains sample data provided during the application entitlement process. Therefore, this endpoint should be requested to gather necessary information unlike the sprint testing and bug fest.
This issue was discussed in the Team chat which involved several people from different teams, including Spitfire () and Eureka ( ). The final conclusion was the same.
The issue could easily be reproduced on any environment by invoking the PUT request to the /eholdings/kb-credentials/80898dee-449f-44dd-9c8e-37d5eb469b1d endpoint.
In this task description, I detailed the specific piece of code where this occurs. To demonstrate this, I debugged the module code using Telepresence.
Khalilah Gambrell February 13, 2025 at 10:42 PM
Hey - I do not understand
Is not LOC using eholdings app on the production Eureka - ECS environment?
I am 100% positive that the eholdings app was tested and is available on Eureka ECS/non-ECS bugfest environment.
So I do not understand why it is working in Eureka bugfest environments and not on Eureka snapshot and sprint environments.
Is it possible to ask the Eureka team or EBSCO FSE team to investigate this issue?
Also can the description be updated to describe the problem and what environments are impacted?
Pavlo Smahin February 12, 2025 at 11:11 AM
, I think you shouldn’t post credentials here.
Details
Details
Assignee
Reporter
Priority
P3
The Eureka platform supports two authorization methods: ordinary users and Keycloak clients.
In the case of Keycloak clients, the folio-holdingsiq-client encountered a problem when the user_id was missing from the x-okapi-token. This resulted in a failure while trying to store the configuration in the cache because it requires the format user_id: Configuration_class_object, and the key cannot be null. Consequently, this leads to the following error during the request.
The error happens here
x-okapi-token example:
You should change that behavior to meet the Eureka platform needs.
Update: The issue appears on any environment at any time with the Keycloak client credentials token.
To reproduce:
1. Request the following endpoint to get the client credentials.
https://<keycloak-url>/realms/<tenant_name>/protocol/openid-connect/tokenThe body should contain the
client_id: <SOME_CLIENT_ID>
client_secret: <SOME_CLIENT_SECRET>
grant_type: "client_credentials"
Request the following endpoint with the previously obtained credentials putting them in the header with the Authorization key.
https://{{kong_fqdn}}/eholdings/kb-credentials/80898dee-449f-44dd-9c8e-37d5eb469b1dand with the following body
the content type should be the following
application/vnd.api+json