Handle token from backend

[anna-otrokhova]

Recently we’ve got a request from Rob, that we should handle JWTs in all responses from backend side on React version. We discussed it with our team and found that to implement it we should add a new handler to our middleware, this way we are able to handle all responses to our requests.

Related issue: PulseTile/PulseTile-React-Core#131
PulseTile/PulseTile-AngularJS#75

[kbeloborodko]

Hi, @robtweed could you please provide information how do you plan to send the token in the payload?
Our suggestion is to send the token in the data object of the payload, so we can retrieve it in the following fashion response.payload.data.token. Does it work for you?

[robtweed]

Every JSON response from the new middle tier will include a top-level property named token which will contain the latest version of the JWT that you should use as the new JSESSIONID cookie value, eg this kind of pattern

{
"dirname": "/opt/qewd/mapped/modules/ripple-openehr-jumper/lib",
"headings_built": [
"problems"
],
"token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1MjAzMzQyMzUsImlhdCI6MTUyMDMzMzkzNSwiaXNzIjoicWV3ZC5qd3QiLCJhcHBsaWNhdGlvbiI6InJpcHBsZS1vcGVuZWhyLWp1bXBlciIsInRpbWVvdXQiOjMwMCwicWV3ZCI6Ijc0NGIwMDc2OGI2NzExMmI0ZjdkODVmNjlhYTMzOWU1ZjFmZTViZmEwZjYyYjRlMDZhZmQ2ZGYyOWY0MmIxY2JkOTBmMTg3MDc1ZWY2OTNjMzJhMTFjMDU2ZWJhZWE5NGNiM2ZlYmVlNmM1MzA5MjZjZGZkNDM2MzMxMDVhNzBlNjYzNDE3MmM0N2Q5YWNkMzM0ZDVkNDVhYTNmOWZjYWE0NjQxMjU2YmZiNzA3NmM2IiwidXNlck1vZGUiOiJhZG1pbiIsImdpdmVuX25hbWUiOiJSb2IiLCJmYW1pbHlfbmFtZSI6IlR3ZWVkIiwiZW1haWwiOiJyb2IudHdlZWRAZ21haWwuY29tIiwicm9sZSI6IklEQ1IiLCJyb2xlcyI6WyJJRENSIl0sInVpZCI6IjE5ZDU4OTc2LTgxMjUtNDkzMS1iNjczLWNhYjFlOTliYjAzYSJ9.FP1O0xrLeikMe5xrX1B6D4A6p7J1_F2wiPiJzDHvtms"
}

[kbeloborodko]

Hi, @robtweed thank you for the information. Could you please clarify where the data itself is going to be stored? Inside of the headings_built property for all of the headings? Should we follow this pattern for all PulseTile requests or this could be changed in the future?

[robtweed]

There will be no change to the responses you receive already. All I'm saying is:

• most responses will include a top-level "token" property
• the token is no longer an opaque string but a JWT
• you still handle the token as before - put it into the JSESSIONID cookie
• EVERY TIME you receive a token in a response, you MUST update the JSESSIONID cookie

NOTHING ELSE changes for you as far as the responses from QEWD.

However, as the token is a JWT, you can optionally begin to use its contents within PulseTile if you wish. You will be unable to modify its contents, as it is digitally signed by the QEWD middle tier and you don't have access to its secret key. However you can read its contents - if you wish - it's up to you if you want to make use of its session information.

[robtweed]

If you want to see what I mean, run Ripple against the new middle tier:

http:https://www.mgateway.com:8084

and, using Chrome Dev Tools, look at the responses. You'll see that they are identical to before (which is why PulseTile still works against the new middle tier), but you'll see that there's a token property containing a very long string which is the JWT. That's the ONLY change as far as you're concerned.

[kbeloborodko]

@robtweed thank you very much for the explanation, it looks clear now. We were assuming that you will wrap the data in a separate object to distinguish it from token, this way we would need to change the response data reference.

[kbeloborodko]

@robtweed there is one more question, that arose today: endpoints for the headings contain an array of objects rather than a top-level object itself, where will the token be stored in this case? Attaching problems heading response as an example https://www.screencast.com/t/LfBmTMfF.

CC: @tony-shannon