You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Passing credentials in options.username and options.password that contain "unsafe" characters leads to applying encodeURIComponent to them with wrong Base64-encoded string as a result.
Actual behavior
Making a call with {"username": "test@test", "password": "123456"} results to having the following authorization header:
Authorization: Basic dGVzdCU0MHRlc3Q6MTIzNDU2
After decoding we get the string: test%40test:123456
Expected behavior
Reference call via cURL will result differently:
curl -u 'test@test:123456' -v 'http://localhost:3000/'
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
* Server auth using Basic with user 'test@test'
> GET / HTTP/1.1
> Host: localhost:3000
> Authorization: Basic dGVzdEB0ZXN0OjEyMzQ1Ng==
> User-Agent: curl/7.58.0
> Accept: */*
curl -v 'http://test%40test:123456@localhost:3000/'
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
* Server auth using Basic with user 'test@test'
> GET / HTTP/1.1
> Host: localhost:3000
> Authorization: Basic dGVzdEB0ZXN0OjEyMzQ1Ng==
> User-Agent: curl/7.58.0
> Accept: */*
Decoding the Authorization header results to test@test:123456 as expected.
Just as a comment: very easily reproducing. Launch Node.js CLI (node -i), and then type:
const{URL}=require('url');consthttp=require('http');consturl=newURL('http://localhost');//doesn't matter whether there is listening server here or noturl.username='test@test';url.password='123456';console.log(http.get(url,()=>{}).outputData);
Describe the bug
Passing credentials in
options.username
andoptions.password
that contain "unsafe" characters leads to applyingencodeURIComponent
to them with wrong Base64-encoded string as a result.Actual behavior
Making a call with
{"username": "test@test", "password": "123456"}
results to having the following authorization header:After decoding we get the string:
test%40test:123456
Expected behavior
Reference call via cURL will result differently:
Decoding the Authorization header results to
test@test:123456
as expected.Code to reproduce
Checklist
The text was updated successfully, but these errors were encountered: