We’re using axios to POST a JWT back to the /continue endpoint, with all the keys that the docs indicates are required (including state), but this results in a 400 Bad Request.
If instead we redirect with a GET putting the session_token and the state as query params, everything works, but this is counter to the recommendation in the docs which (maybe?) indicate that POSTing is necessary ‘to avoid replay attacks’.
Is there something missing from the docs regarding what needs to be included/configured for a POST to the /continue endpoint. Is a GET request a security concern/not recommended?
The state claim is part of the jwt (newToken) i.e. you can see it if you decode the below at jwt.io. Although I had already tried what you suggest, and the error remains the sameedit: the error is then a 401 (here’s a gist of that error).
Really appreciate your help on this. Just wondering if you’re able to help further with this issue? A redirect to /continue with state works but an axios POST to /continue with state doesn’t work (David shared the error above).
The documents don’t make it super clear, should a POST work?
Many thanks for the help, after a few days of debugging and trawling documents any light you can shed or help you can offer would be very much appreciated.
I’d previously pursued that line of enquiry but had concluded it wasn’t the root of the issue. I’ve had another bash this morning, sending all the cookies along with the POST, but still getting a 401.
I’d love to get to the bottom of this for 1. anyone else who encounters this issue and 2. my own sanity. But in the meantime we’re going to resort to using the management API and circumvent the requirement to do it this way.
I couldn’t see any immediately relevant-looking cookies (hence why I sent them all along). Do you know which one/ones we should be looking for?
I’ll probably keep tinkering away at it to see what I’m missing.