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
Describe the bug
On Windows Platforms, when using Credential Manager to store the basic Auth user/pass, the base64 encoded string will be wrong, causing authentication to fail.
Please provide following details
JiraCLI Version: 1.5.2
Are you using Jira cloud or on-premise jira server? Local
What operating system are you using? Windows 10
What terminal are you using? Neovide nvim cmd.exe terminal
To Reproduce
Set up jira-cli init using basic auth
In Windows Credential Manager, create new generic key in the following format:
Internet or Network address: jira-cli:[username]
Username: [username]
Password: [password]
Expected behavior
Authentication works with properly encoded base64
Additional context
What seems to be happening is that the keyring/credman go packages return stored secrets as utf16(?) encoded strings, containing \0 bytes after every character byte. This results in a base64 encoded string that is around double the size of the expected base64 string.
Using --debug will show the wrong base64 auth header being sent.
A hacky solution taken from stackoverflow is to fix the apitoken where it is set in client.go:44
I'm not a go user and took a quick look at Go strings, but couldn't figure out the proper way to deal with this. Happy to create a pull request if you'd want to move forward with this solution.
The text was updated successfully, but these errors were encountered:
Describe the bug
On Windows Platforms, when using Credential Manager to store the basic Auth user/pass, the base64 encoded string will be wrong, causing authentication to fail.
Please provide following details
To Reproduce
Expected behavior
Authentication works with properly encoded base64
Additional context
What seems to be happening is that the keyring/credman go packages return stored secrets as utf16(?) encoded strings, containing \0 bytes after every character byte. This results in a base64 encoded string that is around double the size of the expected base64 string.
Using --debug will show the wrong base64 auth header being sent.
A hacky solution taken from stackoverflow is to fix the apitoken where it is set in client.go:44
I'm not a go user and took a quick look at Go strings, but couldn't figure out the proper way to deal with this. Happy to create a pull request if you'd want to move forward with this solution.
The text was updated successfully, but these errors were encountered: