fetchToken module fails to parse unfederated server response

[joelhickok]

Version: @esri/arcgis-rest-request 4.1.1
Module: fetchToken
Environment Info: Importing esm module using Vite in a SvelteKit project.

Description:
When making a token request to an un-federated ArcGIS Server, the token response is successfully received. However, then the fetchToken function fails to properly handle the response body.

Question:
Is the fetchToken handler supposed to be so limited and unable to handle the response from ArcGIS Server 10.9? Or am I supposed to be doing this using a different method?

For example, if the response JSON has a token property and an expiration property, you can see the fetchToken function is only smart enough to get a response property called access_token and not a property called token.

Also, in the above mentioned case, the expiration is not parsing correctly.

// my code
const params = {
  f: 'json',
  username: '{USER_NAME}',
  password: '{PASSWORD}',
  referer: event.url.origin,
  expiration: 5,
}

const response = await fetchToken('https://{MY_SERVER_DOMAIN}/arcgis/tokens/generateToken', {
  params,
}).catch(err => err)

console.log(response)

/*
 {
  token: undefined,
  username: undefined,
  expires: Invalid Date,
  ssl: false
}
*/

However when I modify the module to debug with some console.log output, I can see the token is being generated and not return properly:

import { request } from "./request.js";
const FIVE_MINUTES_IN_MILLISECONDS = 5 * 60 * 1000;
export function fetchToken(url, requestOptions) {
    const options = requestOptions;
    // we generate a response, so we can't return the raw response
    options.rawResponse = false;
    return request(url, options).then((response) => {

        console.log(response)

        /*
        {
          token: '{VALID_TOKEN_IS RETURNED_HERE}',
          expires: 1667322264355
        }
        */

        const r = {
            token: response.access_token, // <---- handle response.token?
            username: response.username,
            expires: new Date(
            // convert seconds in response to milliseconds and add the value to the current time to calculate a static expiration timestamp
            // we subtract 5 minutes here to make sure that we refresh the token early if the user makes requests
            Date.now() + response.expires_in * 1000 - FIVE_MINUTES_IN_MILLISECONDS),  // date handling??
            ssl: response.ssl === true
        };
        if (response.refresh_token) {
            r.refreshToken = response.refresh_token;
        }
        if (response.refresh_token_expires_in) {
            r.refreshTokenExpires = new Date(
            // convert seconds in response to milliseconds and add the value to the current time to calculate a static expiration timestamp
            // we subtract 5 minutes here to make sure that we refresh the token early if the user makes requests
            Date.now() +
                response.refresh_token_expires_in * 1000 -
                FIVE_MINUTES_IN_MILLISECONDS);
        }
        return r;
    });
}

[patrickarlt]

@joelhickok while this should be fixed once #1093 is released I have to caution you against asking for a username/password in a client side app. Ideally the server should get federated with a portal and you should use oAuth 2.0 for access to it. Having a user enter their password into an app is definitely not a security best practice at this point.