JSAPI4: Intercept requests to add custom headers

11-06-2017 02:34 AM
New Contributor III

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.

Tags (1)
0 Kudos
9 Replies
Regular Contributor

setRequestPreCallback should also work in 4.XX I believe.

0 Kudos
New Contributor

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. 

0 Kudos
New Contributor III

As specified by Thomas, the setRequestPreCallback will work with 4.x. It is just not documented.

0 Kudos
New Contributor III

I realize this is an old thread but a 4.8 the documentation shows the new way to handle interceptors: config | API Reference | ArcGIS API for JavaScript 4.8 

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.

for example

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)

any ideas?

0 Kudos
Esri Regular Contributor

Justin is correct. The way to intercept and modify requests is with the RequestInterceptor, introduced at version 4.8. 

Release notes for 4.8 | ArcGIS API for JavaScript 4.9 

config | API Reference | ArcGIS API for JavaScript 4.9

@Justin, do you have a sample or a code snippet you could share, so we could take a look? 

0 Kudos
New Contributor III

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.

this.esriConfig.request.interceptors.push({ before: this.EsriRequestInterceptor.bind(this) });

* A place to intercept esri requests
* was looking at this at one point for JWT Token Auth
* @param ioArgs
EsriRequestInterceptor(ioArgs: any) {
// Renew the jwt
if (this.auth.isClientTokenExpired()) {

if (ioArgs.url.toLowerCase().startsWith(`${environment.webApiUrl}/map`.toLowerCase())) {
const idToken = localStorage.getItem('client_token');
// console.log('Modifying Request', idToken);
ioArgs.requestOptions.headers = ioArgs.headers || {};
ioArgs.requestOptions.headers.Authorization = 'Bearer ' + idToken;
ioArgs.requestOptions.query = ioArgs.requestOptions.query || {};
ioArgs.requestOptions.query.pantheon = idToken;
Esri Regular Contributor

Hmm. It could be related to the responseType of the esriRequest:

When this value is image the headers and timeout options are ignored.

esriRequest - RequestOptions - responseType 

request | API Reference | ArcGIS API for JavaScript 4.9 

If this is the case, we could consider making an enhancement at a future release.

0 Kudos
New Contributor II

Is there any movement on this?  I'm curious why this exception is there.  Is it just codebase related or some functional issue.  Are there any workarounds?  

0 Kudos
Esri Regular Contributor

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.