RTR: Refactor x-okapi-token uses to use HTTP Header Cookies. (fw-cli)

[kaladay]

From Spike: #109

The

fw-cli/okapi.js

Line 32 in c68a1cc

server.post('/authn/login', function (req, res) {

needs to be changed.

Support for the folioAccessToken and folioRefreshToken has already be enabled in a past commit.

Actions

1. Change the default /authn/login end points to use the new end point.

2. Update all documentation, readmes, wiki, etc...

Additional References and Quotes

Any scripts or 3rd party integrations with FOLIO that relied on the legacy, non-expiring tokens will need to be changed to use the new authn/login-with-expiry endpoint. Unlike the legacy endpoint, the new endpoint only returns the AT in the form of a Set-Cookie header in the HTTP response. To get the AT, client code needs to parse the cookie string to extract the AT since the cookie string contains other elements besides the token. What follows is an example of the cookie contents of a Set-Cookie headers returned from the login response.

Note that the response from login in contains two Set-Cookie headers, one for the RT and one for the AT. Client scripts only need concern themselves with the AT. If a new AT is needed, client code should request a new one by logging in again and not bother using the refresh endpoint.

quotes from: https://folio-org.atlassian.net/wiki/spaces/FOLIJET/pages/1396980/Refresh+Token+Rotation+RTR#A-guide-for-non-module-clients-such-as-scripts-or-other-integrations

We will eventually switch to Eureka.
Designs should keep in mind that the AT behavior will eventually change to something like the query below:

curl -sS -X GET \
  "http://kong:8000/users-keycloak/users/<folio-user-uuid>" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "x-okapi-tenant: diku"

See the following:

• https://github.com/TAMULib/fw-cli/blob/main/okapi.js
• https://github.com/search?q=repo%3ATAMULib%2Ffw-cli%20token&type=code
• https://github.com/search?q=repo%3ATAMULib%2Ffw-cli%20folioAccessToken&type=code
• 2142c18