Hi Team, We're facing an issue with Gooddata CN authentication via Auth0. Scenario: • Auth0 session seems to expire within 4 hours. • User logs in via Auth0 and leaves the tab open. • on return,

GET /api/v1/entities/workspaces

return

400 Bad request

. • Clearing specific cookies doesn't help. • Only full cookie clear allows the request to succeed again. Auth setup:

const throttleHandler = throttle(redirectToTigerAuthentication, 500, { leading: false, trailing: true});

const backend = tigerFactory({hostname}).withAuthentication(

new ContextDeferredAuthProvider(throttledHandler)

};

Call:

await Promise.allSettled([

dispatch(createUserAccountAsync(payload)),

backend.workspace().forCurrentUser().query(),

]);

Can you help identify the root cause? Let us know if anything in our setup is incorrect. Thanks, Prashant

Hello Prashant, you should be able to set the expiration for the token in Auth0 as mentioned HERE

But why are we getting 400 Bad Request?

I'm sorry, I understood that the expiration was set to 4 hours and that the call was being made after that 4 hour expiration time period.

the expiration of auth0 of our application is 4 hours.

So the failed GET call is taking place within that 4 hour time period, correct?

Hey @Joseph Heun, why the failed call returns 400 in place if cookies are expired?

Cookies may become invalid when the OIDC provider session expires. In such cases, the browser must re-initiate the authentication flow. You can find more information here: https://www.gooddata.com/docs/cloud-native/3.36/manage-organization/set-up-authentication/oidc-cookies/

If the Cookies are expired, shouldn't it a return 401 instead?

@Joseph Heun we do understand about re-initiation of auth flow and that is done as well in case 401 error is returned. However in this case, /api/v1/entities/workspace is returning 400 Bad request. So thats why the auth flow is not reinitiated. We need to understand: 1. What can be the possible reason of workspace api call returning 400 bad request. 2. It starts working fine after clearing the cookies. 3. How do we handle such scenario?

I'm going to pass this over to our L2 technical support team to review the setup and the error returned.

Hey @Joseph Heun, any update on this? This is of priority.

The case is still being reviewed on our end. However, if you could make the GET call and provide a related traceID from the 400 error it might help us track down the cause in our logs

Hi @Joseph Heun, this is the Id we got in logs:

d420f5b700d16ead681087102651b4e0

Hi @Prashant Sharma, Radek here! Apologies for the confusion, Joe was thinking about the Cloud while you are CN-based, so we don't get any logging on our end 🙂 The 400 is strange for sure.. it is of course possible for you to send us the logs from your CN and they would have more insight, but I might be able to tell enough from a HAR file reproducing the issue - do you think it'd be possible for you to share it with me via private message? Many thanks!

Sure