unable to run jira init

[laxmij-cmd]

Hi,

I have to use jira-cli on "on-premise installation" of jira. I did following:

Now when I run "jira init" error is

Installation type: Local Link to Jira Server: <link to our jira server" Login username:

Received unexpected response '401' from jira. Please try again

With I can login to .

Please help.

Thanks Laxmi

[laxmij-cmd]

updating:

Login username:

With I can login to our jira server.

[laxmij-cmd]

not sure why login-id is getting removed

[choman]

@laxmij-cmd Make sure you have both JIRA_API_TOKEN=<api_token> and JIRA_AUTH_TYPE=bearer

[ankitpokhrel]

@laxmij-cmd do you still need help?

[cgpu]

I am having the same issue as above reported by @laxmij-cmd.

I am setting as env variables

JIRA_API_TOKEN="<api_token>"  # not base64 encoded, exactly as copied from https://id.atlassian.com/manage-profile/security/api-tokens
JIRA_AUTH_TYPE=bearer

The following command works for me:

curl --request GET \
  --user "<email>:$JIRA_API_TOKEN" \
  --url 'https://<host>.atlassian.net/rest/agile/1.0/board?projectKeyOrId=DEL'

But the jira init command fails with

jira init
? Installation type: Cloud
? Link to Jira server: https://<host>.atlassian.net
? Login email: [email protected]

✗ Received unexpected response '403 Forbidden' from jira. Please try again.

We tried with my organisation admin and they also have the same issue, so I can rule out the problem being insufficient permissions.

Any idea what I may be doing wrong?

[mattiapesentiAGADE]

I noticed the same behavior on Windows 10 under Git Bash (MINGW64_NT-10.0-19045). The curl request works, but then jira init fails with ✗ Received unexpected response '403 Forbidden' from jira. Please try again.

I'm using this version:

$ jira version
(Version="1.5.1", GitCommit="0e0f82d52ef5a775d2cc662fbe38d9732b9b5c59", CommitDate="2024-01-20T10:48:06+00:00", GoVersion="go1.21.5", Compiler="gc", Platform="windows/amd64")

[armadsen]

I'm having the same problem. I'm on macOS 14.2.1 with ZSH. I've set JIRA_API_TOKEN and JIRA_AUTH_TYPE in .zshrc. When I run Jira init, provide my JIRA instance URL, then login email, I get:

Received unexpected response '403 Forbidden' from jira. Please try again.

As with others, using curl returns the expected data.

[erawhctim]

Same problem here. I've tried installed a handful of versions (1.5.4, 1.5.0, 1.4.0, 1.2.0), all see the same issue.

[erawhctim]

@ankitpokhrel What information can we get you that's most helpful to debug, if anything?

[ankitpokhrel]

Hey Folks, I'll look into this this week. Could you please provide some more details like:

• If this is jira cloud or jira server
• If using jira server, what version of Jira is it
• Any other details that may be helpful to debug the issue

Also, if you are using Jira Cloud you may NOT need to set JIRA_AUTH_TYPE=bearer. API tokens in cloud is different from PAT in on-premises installation IIRC.

[erawhctim]

I'm using Jira Cloud, version 1001.0.0-SNAPSHOT (how to find out your JIra Cloud version)

Removing the auth type param seems to have the same effect; I get a 401 Unauthorized.

This curl command succeeds: curl https://{host}.atlassian.net/rest/api/2/myself --user {email}:$JIRA_API_TOKEN

This jira-cli fails: jira init --force --installation cloud --server "https://{host}.atlassian.net" --login "{email}" --debug

[mattiapesentiAGADE]

Same here Jira cloud version 1001.0.0-SNAPSHOT

$ jira init --installation cloud --server "https://<host>.atlassian.net" --login "<email>" --debug
⠇ Verifying login details...

REQUEST DETAILS
------------------------------------------------------------

GET /rest/api/2/myself HTTP/1.1
Host: <host>.atlassian.net
Authorization: Bearer <JIRA_API_TOKEN>


✗ Received unexpected response '403 Forbidden' from jira. Please try again.

---

EDIT: I changed the auth type (removed the env variable JIRA_AUTH_TYPE=bearer and it worked!

[armadsen]

Exact same thing as @mattiapesentiAGADE. I'm on Jira cloud version 1001.0.0-SNAPSHOT.

I've also just tried removing the JIRA_AUTH_TYPE=bearer ENV variable, and it works now!

[ankitpokhrel]

I'm using Jira Cloud, version 1001.0.0-SNAPSHOT (how to find out your JIra Cloud version)

Removing the auth type param seems to have the same effect; I get a 401 Unauthorized.

This curl command succeeds: curl https://{host}.atlassian.net/rest/api/2/myself --user {email}:$JIRA_API_TOKEN

This jira-cli fails: jira init --force --installation cloud --server "https://{host}.atlassian.net" --login "{email}" --debug

Hi @erawhctim, This is strange as I've the same setup and is working fine. Could you please double check the params you are passing to jira-cli and provide any additional context that might be helpful to debug?

[erawhctim]

I'm creating my PAT via: Account Icon -> Profile -> Security -> Create and Manage API tokens. I can confirm that this value is set correctly for the JIRA_API_TOKEN env. var; is there another way to set this value that I can try? I just created a new PAT this way and tried with that (using the exact script I posed); same result.

My org uses Okta SSO to authenticate with our Jira instance, so perhaps some non-standard auth. setup is interfering here.

Another thing I tried is running this same script within our CI environment, which has an org-level, pre-provisioned Jira API token & service user. That seems to be working! So this might just be something that I can't run locally with user-created PAT's.

Can you help me better understand the auth. request that happens when init is called? I'd like to take this back to our Atlassian tools admins and try and debug further (it'd be nice if we could figure out how to enable people to use jira-cli locally).

[oren-adhoc]

make sure to export JIRA_API_TOKEN in your environment:

export JIRA_API_TOKEN=xxxxx

[Drew-Daniels]

Same issue here. I've set these in my ~/.zshrc:

JIRA_AUTH_TYPE=bearer
JIRA_API_TOKEN=<my-token>

I can verify these return the expected values with echo, and I can successfully run this curl command:

$ curl https://{host}.atlassian.net/rest/api/2/myself --user {email}:$JIRA_API_TOKEN

But when I run jira init and select "Local", enter my Jira server, and my login username, I get a 403 error response.

$ jira init

Installed jira-cli with brew as described here

$ jira version
(Version="1.5.1", GitCommit="0e0f82d52ef5a775d2cc662fbe38d9732b9b5c59", CommitDate="2024-01-20T10:48:06+00:00", GoVersion="go1.21.5", Compiler="gc", Platform="darwin/arm64")

[ankitpokhrel]

HI @Drew-Daniels, its a cloud installation if your domain is {host}.atlassian.net. Please select Cloud as installation type and try again.

[Drew-Daniels]

HI @Drew-Daniels, its a cloud installation if your domain is {host}.atlassian.net. Please select Cloud as installation type and try again.

Ah, my mistake. Thanks for pointing that out. As soon as I removed the JIRA_AUTH_TYPE env var from .zshrc and chose Cloud as the installation type jira init worked.

Thank you!

[ankitpokhrel]

@erawhctim

My org uses Okta SSO to authenticate with our Jira instance, so perhaps some non-standard auth. setup is interfering here.

Strange! My org uses Okta SSO too and I don't have any issue with the tokens.

Can you help me better understand the auth. request that happens when init is called?

It basically calls bunch of JIRA API to generate the config file. First it verifies login details using /myself endpoint, and if that's successful it will fetch project and board details.

[rcoleman-hivewatch]

fwiw i was struggling with the same issue but when i unset JIRA_AUTH_TYPE and ran jira init again, things worked.

[pot8228]

I had the same problem. New Jira Cloud instance, authorised through Apple ID. Jira init 403'd each time. PAT seemed to be fine, I could curl with it.

The fix, as per the last comment, was to remove JIRA_AUTH_TYPE=bearer from my environment variables. Connects fine now.

[justinphelps]

FWIW. I went through ALL the troubleshooting steps I could find trying to resolve 401s for a couple of days.
I had a brand new fresh cloud install. What finally worked as creating a second, non-privileged user with another email address and it finally worked. I'm guessing there is some permission that is excluded from users with the jira-admin role.