Open masukomi opened 1 year ago
Hi @masukomi, I am also using jira-cli with SSO in my company but its a self-hosted Jira Server. I think it should work if are able to generate Personal Access Token (PAT).
Basically what I am doing is:
JIRA_AUTH_TYPE
to bearer
JIRA_API_TOKEN
to the generated personal access tokenjira init
and use your email or username.I started using it today and had the same problem.
Turned out to be an old version I had lying around in .local/bin
. :)
I tried to use it before we could create PATs, which didn't work, but now it does so I tried again.
So as another data point I can report that it works great with my employer's Jira installation, which uses SSO (AD-based I believe).
@masukomi Have you tried using the username that appears on your Jira profile page, instead of an email address, if they differ? That username + PAT works for me.
You can also try jira init --debug
and see if there's anything interesting, if you haven't already.
Verify that it says Authorization: Bearer jFLKsajflksDetc
in the request.
You can also check for failed logins on your Jira profile, then you know if jira-cli has made it that far.
@ankitpokhrel Thanks for this tool, it's a nice accessibility aid for me. :)
same issue for me:
Set JIRA_AUTH_TYPE to bearer Generate PAT (Click on your pic in Jira -> Profile -> Personal Access Tokens) Set JIRA_API_TOKEN to the generated personal access token Run jira init and use your email or username.
Results in: Received unexpected response '401 Unauthorized' from jira. Please try again.
Weird thing is that I can see token being used by going to jira, it shows that it has been used within a minute which leads me to think that maybe it's "permissions to use API on jira/Atlasian" side of things? Is there such a thing?
I'm also having this problem.
What I can tell from jira init --debug
, I'm still using the basic auth even tough, I have enabled the bearer
method via my .zshrc
. I restarted my shell and checked if I can echo the content of the env vars - I could.
My company uses a SSO service, that I don't know. Also, we are selfhosting. -> I selected Local
whilie init. And for the username, I selected the username shown on my Profile Page as well as my email (tried both).
My .zshrc
Is the position inside the file relevant?
JIRA_AUTH_TYPE=bearer
JIRA_API_TOKEN=<imagine my token here>
I use Fedora Linux on a Thinkpad T590. I instlled via homebrew.
My
.zshrc
Is the position inside the file relevant?JIRA_AUTH_TYPE=bearer JIRA_API_TOKEN=<imagine my token here>
@Akorian You need to export them too, export JIRA_AUTH_TYPE=bearer
, to make them available to other programs.
FWIW, I have a work JIRA instance with SSO (via Google Auth). These steps worked for me.
export JIRA_API_TOKEN=<GENERATED_TOKEN>
in your .bashrc
file.JIRA_AUTH_TYPE
setting, it did not work for me when this was set to bearer
I also can't get this to work with SSO (Azure) with any combination I've tried:
.netrc
fileOn macOS, installed via Homebrew. I see the following error:
✗ Received unexpected response '401 401' from jira. Please try again.
I ran into this today as well. @spprashant documented the workaround that unblocks me (don't set JIRA_AUTH_TYPE
)
@comjf / @spprashant are you using local Jira installation? The token generated in local installation is used with basic auth IIRC so we don't need to set JIRA_AUTH_TYPE
to bearer
.
Could we potentially get something like this setup for SSO servers on intranets
Would be nice if instead of that error it will show the suggestion to set these two environment variables.
In my case (Oauth2 SSO with PingId), setting up a bearer token is not enough:
⠹ Verifying login details...
REQUEST DETAILS
------------------------------------------------------------
GET /rest/api/2/myself HTTP/1.1
Host: confluence.[redacted]
Authorization: Bearer [redacted]
✗ Received unexpected response '404 ' from jira. Please try again.
I've verified with my browser that the API endpoint does exists. A similar call is done with my browser. But my browser sends a huge cookie with the request instead of a token.
I guess that jira-cli needs to perform the Oauth dance to be able to log in with PingId.
Hope this helps
@comjf / @spprashant are you using local Jira installation? The token generated in local installation is used with basic auth IIRC so we don't need to set
JIRA_AUTH_TYPE
tobearer
.
@ankitpokhrel I confirmed with my IT admins, we are using the cloud JIRA instance. So unsure why the bearer
setting doesn't work.
I get the same issue with Okta SSO, but only if I'm not on my company VPN.
I've got an SSO in front of my self-hosted JIRA instance. I was able to create a PAT at https://jira.EXAMPLE.COM/secure/ViewProfile.jspa?selectedTab=com.atlassian.pats.pats-plugin:jira-user-personal-access-tokens
and place it in my .bashrc
:
export JIRA_API_TOKEN=<the token>
export JIRA_AUTH_TYPE=bearer
and jira init
ran just fine after asking my login info.
I am using Jira Cloud with Atlassian's SSO and I just need to set this:
export JIRA_API_TOKEN=<the token>
Setting username and password in .netrc
(without manually setting the token) leads to a '401 Unauthorized' because jira init --debug
tries to authenticate using Basic Auth, which I guess is not supported once you move to Atlassian's SSO. When explicitly passing forcing Bearer Token auth with JIRA_AUTH_TYPE=bearer jira init --debug
I see that the value of the bearer token is not sent along.
It'd be nice if we could set the JIRA_AUTH_TOKEN
in the .config/.jira/.config.yml
so I don't have to have such a sensitive token in my env vars at all time. For now I have just created the following alias in my .bashrc
/zsh config:
jira() {
# launch in a (subshell) so the api token doesn't linger in env after running
(source ~/.config/.jira/api_token.env && command jira $@)
}
the api_token.env
file contains:
export JIRA_API_TOKEN=th3t0k3n
If I curl
a jira instance that is behind Amazon Cognito with my PAT in the authorization header and follow the location header like so
curl -L -H "Authorization: Bearer [token]" https://jira.[domain].com/rest/api/2/myself
I get 302
redirected to the Cognito login page so jira init
fails for me.
Describe the bug when using
jira init
it requests an email and immediately errors with401 Unauthorized
. This is, presumably, because at our company we use Single Sign On to authenticate, not our emails.Short term suggestions:
Please provide following details
To Reproduce
Steps to reproduce the behavior:
jira init
and give it a valid email addressExpected behavior I'd expect it to either work, or to provide me with an indication than SSO isn't supported.