Hi, in JSAPI 3.x, it seems that it was possible to intercept the HTTP requests to the ArcGIS Server in several ways, like for example:
- overriding the dojo.xhr function
But I cannot find a way to do this in JSAPI 4.x.
I need to be able to add a custom header field with every request because of some reverse proxy / authentication reason.
It is not documented in the API. Please let me know if this functionality is possible. We are using web-tier authentication with a web adaptor and require a custom authorization header to access secure resources.
however, it's seems not every request is actually modified (even though it goes through the interceptor).
We are using the Before interceptor and every request does get routed through and the params get modified to add an authorization header BUT when the request actually goes out only some requests actually get modified to send the header.
requests to the .../info?f=json endpoint the modified header goes with the request or ../mapserver?f=json does
but mapserver/export or mapserver/identify endpoint requests does not get sent the header (even though set in the interceptor)
Justin is correct. The way to intercept and modify requests is with the RequestInterceptor, introduced at version 4.8.
@Justin, do you have a sample or a code snippet you could share, so we could take a look?
this is an example from an angular project / typescript. The only thing i think of with the headers not getting modified on occasion is what i read about JSONP maybe headers are not passed when wrapped in a JSONP request. I do see a difference when the headers do get passed i see a reference to a callback function int the ioArgs (params), when that callback reference isn't there the headers do not get passed with the request. I'm going to use a custom query param (pantheon below) instead as that always seems to get passed on every case. Hope this helps.
Hmm. It could be related to the responseType of the esriRequest:
When this value is
timeout options are ignored.
esriRequest - RequestOptions - responseType
If this is the case, we could consider making an enhancement at a future release.
Hi Travis, looks like we have this fixed for the upcoming 4.10 release, due out in mid-December. The "headers" will now be honored when the value type is "image". I can't say with any degree of confidence why the exception was there, but I can tell you that user feedback really helps us drive the product forward. I am also not sure of a workaround at this point. Hope this helps.