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
In the first form, the result is automatically base64 encoded, in the second, it's assumed the value already is and no further encoding is performed.
There are certain API (namely, SonarQube) that support both user/pass or token to be passed via a basic auth header; however in Sonar's case, the token is passed in as the {{user}} and the {{password}} should be empty...effectively just base64 encoding the token.
There doesn't seem to be a way to have Rest Client detect this automagically--in essence, provide a raw token, and have it base64 encoded like it already does with the user/pass form.
Tried providing an empty password by putting a single space after the {{token}}, but that doesn't authenticate properly: Authorization: Basic {{token}} <--trailing-space
If I manually base64 encode my token value and use that instead, all works well: Authorization: Basic {{token-base64}}
Using the curl form with an empty password works fine too...notice the colon after the 'user' (really the token in this case): curl -u {{token}}: http://localhost/sonar/api/user_tokens/search
Is there a way to indicate the single value following the 'Basic ' needs to be base64 encoded (i.e. the password is empty)? This would save the step of having to encode the single token manually outside of Rest Client.
The text was updated successfully, but these errors were encountered:
In SonarQube's case, the value that needs to be encoded is "{{token}}:"...your generated token plus the standard colon that separates a user and password.
Is the only way to trigger automatic encoding to provide {{user}} {{password}} separated by a space?
Might be nice to support this as well:
Authorization: Basic {{user}}:{{password}}
On one hand, it matches the format normally used--the colon is encoded as part of the string, correct? On the other, it would allow people to be explicit about password values. Sending an empty password would be done like this...similar to how it's represented in the curl command.
The two forms of basic authentication supported are:
In the first form, the result is automatically base64 encoded, in the second, it's assumed the value already is and no further encoding is performed.
There are certain API (namely, SonarQube) that support both user/pass or token to be passed via a basic auth header; however in Sonar's case, the token is passed in as the {{user}} and the {{password}} should be empty...effectively just base64 encoding the token.
There doesn't seem to be a way to have Rest Client detect this automagically--in essence, provide a raw token, and have it base64 encoded like it already does with the user/pass form.
Tried providing an empty password by putting a single space after the {{token}}, but that doesn't authenticate properly:
Authorization: Basic {{token}} <--trailing-space
If I manually base64 encode my token value and use that instead, all works well:
Authorization: Basic {{token-base64}}
Using the curl form with an empty password works fine too...notice the colon after the 'user' (really the token in this case):
curl -u {{token}}: http://localhost/sonar/api/user_tokens/search
Is there a way to indicate the single value following the 'Basic ' needs to be base64 encoded (i.e. the password is empty)? This would save the step of having to encode the single token manually outside of Rest Client.
The text was updated successfully, but these errors were encountered: