interceptors: ClientRequestInterceptor incorrectly encodes basic authentication header

Our application uses Axios to send basic authentication requests to a 3rd party application. This integration works ok until we add the ClientRequestInterceptor (for logging purposes). The interceptor seems to apply url encoding when it should not.

Authorization header without interceptor (after base64 decoding): user@xyz.com:password Authorization header with interceptor (after base64 decoding): user%40xyz.com:password

About this issue

Original URL
State: closed
Created 2 months ago
Reactions: 2
Comments: 15 (15 by maintainers)

Most upvoted comments

Released: v0.29.1 🎉

This has been released in v0.29.1!

📄 Release notes
📦 npm package

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.

Predictable release automation by @ossjs/release.

kettanaito on Apr 29, 2024

The integration with Axios (without the interceptors) works without problems but fails when we add the interceptor.

I suspect this is due to Interceptor coercing your request options to a URL instance, which escapes the auth by default (which, per the RFC, seems like the right thing to do).

That is not the case for basic authentication… axios encodes as base 64 and puts the content in the Authorization header.

Oh, that’s a huge oversight on my part! For some reason, I thought we are talking about the auth-in-URL (I think the username email threw me off). Let me give this test another try…

kettanaito on Apr 24, 2024

hi @kettanaito , thanks for the help (and for the great library 👍 ) we are using basic authentication as documented here

  auth: {
    username: 'user@xyz.com',
    password: 's00pers3cret'
  }

mdesousa on Apr 24, 2024