Issue with Prodigy oauth idp (keycloak) integration

, , ,
#1

Hi,

We are setting up a prodigy oauth idp (keycloak) integration, and have it mostly working, but we are hitting a problem in the case where a token needs to be refreshed for a call from javascript.

In this situation we have a flow like

  1. prodigy XMLHttpRequest -> API GW in front of prodigy backend
  2. API GW wants to refresh token -> redirect to IDP
  3. prodigy XMLHttpRequest follow redirect -> IDP
  4. etc

We would like to have cors enabled in prodigy, and so we have enabled in the config.

As a result on step 3) a cors preflight request is triggered, and we return the appropriate cors headers.

With cors satisfied, the actual request is sent to the idp, but the idp cookie is missing.

Therefore the question:

Do you set 'withCredentials' property to 'true' on the XMLHttpRequest object that executes requests from js?

For an explanation, see e.g. Cross-Origin Resource Sharing (CORS) - HTTP | MDN

Thanks for your help!

Vincent

#2

Hi! Prodigy should enable CORS by default and the request sets credentials: 'same-origin', but not withCredentials: true. I'll need to look into this in more detail but it should probably be fine for the Prodigy app to send withCredentials: true by default, especially if CORS isn't explicitly disabled.

In the meantime, can you work around this by putting a reverse proxy in front of the web app?

Edit: Ah, so the fetch equivalent would be credentials: 'include', as described here? I would have to do some more testing there because I'm unsure what the implications or side-effects of changing same-origin to include would be.

#3

Thanks for the reply @ines ! A reverse proxy will be very difficult (or maybe even impossible). We're proxying our IDP, so that's something we'd prefer not to tamper with.

Alternatively, would it not be possible to make that setting configurable from the prodigy.json?