use an "X-Esri-Authorization" header to pass along tokens (not a query parameter)

[jgravois]

see #290 (comment) for more info.

[jgravois]

i did some testing with this and currently hosted feature services honor tokens pass via an X-Esri-Authorization header, but endpoints like /search do not.

probably best to put this enhancement "on ice" for now.

[ssylvia]

Did some basic testing with Postman and it appears that /search endpoint does work with this header. After communication with others, it appears that support was added for this header a few years back for AGO. It's also supported in portal as of 10.5.1.

I'll take a stab at adding support for this in a PR. This is my plan if you have any feedback before I start:

1. Add new options to IRequestOptions
   • secureToken: boolean (hides the token in POST body or GET header)
   • mode: FetchMode (standard fetch mode: cors, no-cores, etcs). Looks like custom headers are only supported over fetch when cors mode.
2. If secureToken is true, we'll convert all GET requests to POST, unless the mode is also cors, in which case we'll append the token in the X-ESRI-AUTH.. header.
3. I'll leave both of these off by default so it can be merged in a patch release. Then we can add them to the default setting at a major release if we choose to.

[jgravois]

it appears that /search endpoint does work with this header.

i'm sure i was just doing something wrong. it's been awhile, but i don't remember Bearer being in the examples last year.

If secureToken is true, we'll convert all GET requests to POST

just curious, what is the benefit of that?

[ssylvia]

If secureToken is true, we'll convert all GET requests to POST
just curious, what is the benefit of that?

X-ESRI-AUTHORIZATION header is not allowed in the request headers when fetch is using no-cors, which is default. To prevent the token being leaked in query param, we will convert to POST so it is placed in body.