Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request interceptors should be able to access the expected final URL #4793

Open
boutell opened this issue Jun 17, 2022 · 4 comments
Open

Request interceptors should be able to access the expected final URL #4793

boutell opened this issue Jun 17, 2022 · 4 comments

Comments

@boutell
Copy link

boutell commented Jun 17, 2022

Is your feature request related to a problem? Please describe.

An interceptor cannot be used for request signing purposes because it cannot access the final URL. Generating the final URL yourself involves duplicate logic to interpret the baseURL and params, which is risky and a maintenance burden.

A workaround exists, but relies on "deep imports" which creates an expectation of stability for submodules of Axios that is probably not valid.

Describe the solution you'd like

Export a buildURL method from axios, so that it is possible to call axios.buildURL(config) to predict what the final URL will be using the same mechanisms Axios uses internally. This method would take all appropriate config parameters into account, i.e. baseURL and params, unlike the internal buildURL helper which only really deals with params.

Describe alternatives you've considered

This hack works, but it's probably not stable for the long term:

import buildURL from 'axios/lib/helpers/buildURL';
import buildFullPath from 'axios/lib/core/buildFullPath';

instance.interceptors.request.use(async config => {
  config.headers['My-Signature-Header'] = await sign({
    url: buildFullPath(config.baseURL, buildURL(config.url, config.params)),
    // ... etc.
  })
  return config;
});

I'm guessing you'd prefer folks not rely on that, as lib/helpers and lib/core are not part of the official API of Axios.

Additional context

See also #1549. On that ticket it was suggested that a custom adapter was the way to go, but looking at the source for the core adapters, they depend on importing the same private, undocumented APIs I'm using above so I don't see how this helps.

Thanks for all your work on Axios. It is appreciated.

@Hasan-Jawaheri
Copy link

Yeah I am facing the same issue. Would be great if those functions can be exported or somehow accessible without reaching deep into library implementation

@jamesmbourne
Copy link

This is preventing me from supporting Axios 1.x in https://github.com/jamesmbourne/aws4-axios/ as the AWSv4 signature relies on the final URL.

In previous versions I bolted together buildURL, combineURLs, and isAbsoluteURL but now these are not exported from the module.

I understand the reason for this in not wanting to have any internal change result in a breaking change, but knowing what the final URL Axios is going to make a request to is crucial.

@jamesmbourne
Copy link

@DigitalBrainJS perhaps a duplicate of #5000?

@Mifrill
Copy link

Mifrill commented Jan 2, 2024

any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@boutell @jamesmbourne @Hasan-Jawaheri @Mifrill and others