Specify host for customer headers

This issue is intended as a start of a discussion for adding support to limit the hosts to which custom headers are sent.

mapbox-gl-js map supports a transformRequest option which allows custom headers to be set. It is implemented as a function where you can implement logic to add headers for specific hosts using something like this:

transformRequest: (url, resourceType) => {
        if (resourceType === 'Tile' && url.match('example.com')) {
            return {
                url: url,
                headers: { 'Authorization': 'secret' }
            };
        }
    }

The common use case for transformRequest is to add custom authorisation headers for authenticated tile servers.

In react-native-mapbox-gl/maps you can also add custom headers, but they will be added to every mapbox tile request, not just to a specific host/source. This leaks security sensitive data to mapbox servers (which ignore the headers) and also potentially to other hosts that shouldn’t receive the headers.

I understand that a JS function passed to native code will not work, so the exact same approach as mapbox-gl-js doesn’t fit on the react-native-mapbox-gl model. But because the custom headers intended for specific hosts is such a common thing for anyone using a custom tile server, I propose we solve at least the problem of limiting headers to specific hosts.

I see several ways to solve this and there may be more.

1. add hosts array to addCustomHeader
2. add urlFilter regex to addCustomHeader
3. Either 1 or 2 + customHeaders, but on VectorSource, ShapeSource, RasterSource and ImageSource.

I appreciate any feedback on the problem, the proposed solutions. I’m happy to contribute the solution in a PR if we can settle on an approach.

[dave-moser]

I am having the same issue. I need to sign the request to our map tile provider. I can do this with the react-map-gl component in a web page with the transformRequest option. Is there any similar functionality for react-native-mapbox-gl?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.