nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Personal Access token is not effective to authenticate to get attachments

jean.dahan

The personal access token mechanism seems work only for downloading general info, but it fails for attachments. What could be wrong?

works>>curl --verbose -o k -H "Authorization: Bearer XXX" https://jira.labs.hosting.COMPANY.net/rest/api/latest/issue/ASRDP-1511

fails>>curl --verbose -o k.zip -H "Authorization: Bearer XXX" https://jira.labs.hosting.COMPANY.net/secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip

works>> curl -D- --verbose -u user:pass -o k.zip -X GET https://jira.labs.hosting.COMPANY.net/secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip

The failed case responds with:

* Trying 10.179.105.4...
* Connected to jira.labs.hosting.COMPANY.net (10.179.105.4) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=*.labs.hosting.COMPANY.net,O=COMPANYLLC,L=Burlington,ST=Massachusetts,C=US
* start date: Sep 13 00:00:00 2020 GMT
* expire date: Sep 28 12:00:00 2021 GMT
* common name: *.labs.hosting.COMPANY.net
* issuer: CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US
> GET /secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip HTTP/1.1
> User-Agent: curl/7.29.0
> Host: jira.labs.hosting.COMPANY.net
> Accept: */*
> X-USERNAME: dahan
> Authorization: Bearer xxhiddenxx

HTTP/1.1 302
< X-AREQUESTID: 808x17110062x4
< Referrer-Policy: strict-origin-when-cross-origin
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
< Set-Cookie: atlassian.xsrf.token=BD2V-NTI2-H1R4-850Q_c118ee561d27c623067314f8818211abbc969da9_lout; Path=/; Secure
< X-AUSERNAME: anonymous
< Location: /login.jsp?permissionViolation=true&os_destination=%2Fsecure%2Fattachment%2F556907%2Fce64f351-37fd-4e44-8d63-6fdc27faba88.zip&page_caps=&user_role=
< Content-Type: text/html;charset=UTF-8
< Content-Length: 0
< Date: Thu, 14 Jan 2021 18:28:39 GMT
<

Accepted answers

Andy Heinzer

Hi everyone,

Thanks for the feedback here. Apologies for my initial confusion here. I can see that this problem affects more than a few users. I wanted to share some insights here. Since I now realize this is Jira Server, AND these are specifically personal access tokens, which are a new feature to Jira Server/Data Center in 8.14 and later versions.

These personal access tokens can be used to access REST API endpoints in Jira Server/Data Center. However these attachments are not directly accessible via the REST API. Attachments never have been accessible via REST API to the best of my knowledge. There is no REST endpoint that can return to you the actual attachment itself. Certainly you can find the meta data about these attachments (filename, upload, date, author, etc) via REST, but there has never been the expectation that the attachment itself can be provided via REST. The attachments themselves, historically speaking, are only being served up by Jira's web interface.

Hence even though you might have a valid token, your requests here are being redirected to a login page because your call has no authenticated session yet, and the web interface is not designed to accept the personal access tokens for this kind of authentication. These tokens are designed to work with the REST API, but technically this is something outside that scope.

This also explains why basic auth works here (the web interface is built for that). But more explicitly, basic auth is forcing a login at the time the request is made. I believe that a cookie-based auth curl call would also work here (because the method by which it works creates a session for a particular user that you can then call the attachment URL and if that user has permissions to view that issue, then they can download that file).

That said, I can certainly see why you would want this ability. So I have gone ahead and created a suggestion ticket over in JRASERVER-72019 which seeks to allow these tokens to be used to download attachments in Jira Server or Jira Data Center. I would recommend that you follow that ticket for any updates to this, and vote/watch that issue to help us track this.

Sorry that I do not currently have a better work-around for this particular problem. It does seem like this is something that would be useful to have here, however I believe this is a limitation of this new feature.

Andy

All comments

Andy Heinzer

Hi Jean,
I see that you are trying to download attachments stored in Jira Cloud using curl. While the response you get back is not exactly an error message, I understand that the file it not actually being downloaded/stored as a result of your call. I believe I know why that is now.

Our Cloud services are storing these attachments a bit differently than say a Jira Server or Data Center version would. There actually is a redirect involved here. You can see that redirect in your output here as an HTTP/1.1 302 code in the response you got back. With the current command you have supplied to curl, it isn't able to just follow the redirect automatically.

But this is something we can tell curl to do with the -L switch (make sure it's the upper case L and not the lower case l). That switch specifically tells curl to follow redirects. I tested this in my own Cloud test site, however in my case I was using Basic Authentication. In your case it looks like you are using a JWT authorization bearer token (hence the "Bearer" term in your header vs the "Basic" one in mine). My syntax looks like this:

curl -L -O -H "Authorization: Basic [redacted]" --url https://[yourCloudsite].atlassian.net/secure/attachment/10049/image+(3).png

And I can confirm that this works. I believe the same can be applied to your call as well, but your call would look more like this:

curl -L -o k.zip -H "Authorization: Bearer XXX" https://jira.labs.hosting.COMPANY.net/secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip

Try that and let me know if that works. If it doesn't then try to add that --verbose switch and let me know what output you get back.
I hope this helps.

Cheers,
Andy

jean.dahan

Thanks for your help Andy. Adding the "-L" to follow links does not solve the problem. I also double checked and using the curl command with the -u user:pass continues to work, and does not seem to require the "-L" (it works with and without).

curl -L --verbose -o k.zip -H "Authorization: Bearer XXX" https://jira.labs.hosting.COMPANY.net/secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip

The k.zip content returned is not a zip file (as it should be) but rather an html corresponding to the JIRA login page The verbose log is as follows:

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* About to connect() to jira.labs.hosting.COMPANY.net port 443 (#0)
* Trying 10.179.105.4...
* Connected to jira.labs.hosting.COMPANY.net (10.179.105.4) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=*.labs.hosting.COMPANY.net,O=COMPANY LLC,L=Burlington,ST=Massachusetts,C=US
* start date: Sep 13 00:00:00 2020 GMT
* expire date: Sep 28 12:00:00 2021 GMT
* common name: *.labs.hosting.COMPANY.net
* issuer: CN=DigiCert SHA2 Secure Server CA,O=DigiCert Inc,C=US
> GET /secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip HTTP/1.1
> User-Agent: curl/7.29.0
> Host: jira.labs.hosting.COMPANY.net
> Accept: */*
>
< HTTP/1.1 302
< X-AREQUESTID: 805x18785135x2
< Referrer-Policy: strict-origin-when-cross-origin
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
< Set-Cookie: atlassian.xsrf.token=BD2V-NTI2-H1R4-850Q_78b7125d53ffad8e6f81fc6f56faaab8a4f0d91e_lout; Path=/; Secure
< X-AUSERNAME: anonymous
< Location: /login.jsp?permissionViolation=true&os_destination=%2Fsecure%2Fattachment%2F556907%2Fce64f351-37fd-4e44-8d63-6fdc27faba88.zip&page_caps=&user_role=
< Content-Type: text/html;charset=UTF-8
< Content-Length: 0
< Date: Fri, 15 Jan 2021 18:25:41 GMT
<
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Connection #0 to host jira.labs.hosting.COMPANY.net left intact
* Issue another request to this URL: 'https://jira.labs.hosting.COMPANY.net/login.jsp?permissionViolation=true&os_destination=%2Fsecure%2Fattachment%2F556907%2Fce64f351-37fd-4e44-8d63-6fdc27faba88.zip&page_caps=&user_role='
* Found bundle for host jira.labs.hosting.COMPANY.net: 0x16600a0
* Re-using existing connection! (#0) with host jira.labs.hosting.COMPANY.net
* Connected to jira.labs.hosting.COMPANY.net (10.179.105.4) port 443 (#0)
> GET /login.jsp?permissionViolation=true&os_destination=%2Fsecure%2Fattachment%2F556907%2Fce64f351-37fd-4e44-8d63-6fdc27faba88.zip&page_caps=&user_role= HTTP/1.1
> User-Agent: curl/7.29.0
> Host: jira.labs.hosting.COMPANY.net
> Accept: */*
>
< HTTP/1.1 200
< X-AREQUESTID: 805x18785137x2
< Referrer-Policy: strict-origin-when-cross-origin
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Content-Security-Policy: frame-ancestors 'self'
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: atlassian.xsrf.token=BD2V-NTI2-H1R4-850Q_497b5e60c7588aaab17f59f4621850abc4fcbde3_lout; Path=/; Secure
< X-AUSERNAME: anonymous
< Set-Cookie: JSESSIONID=504388C0171C042AE5A03033B365F0DA; Path=/; Secure; HttpOnly
< X-Atlassian-Dialog-Control: permissionviolation
< Content-Type: text/html;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Fri, 15 Jan 2021 18:25:41 GMT
<
{ [data not shown]
0 0 0 31246 0 0 47266 0 --:--:-- --:--:-- --:--:-- 47266
* Connection #0 to host jira.labs.hosting.COMPANY.net left intact

Thank you.

Andy Heinzer

Sorry to hear that. The fact that this user:pass works here would tend to indicate this is an authentication problem instead of a curl switch problem. Could you let me know some more details about your environment here? Specifically is this a Jira Server/Data Center site? Or a Jira Cloud site?

Initially I thought this was a Jira Cloud site, but from reviewing the responses, it seems more likely this is a Jira Server site. I just want to better understand the site you are trying to make calls to here as the authentication methods are potentially different here. Is this an JWT token? an OAuth token? Just looking to better understand what is being used here so that I can better troubleshoot this problem.

Your first call is a REST API call, in which case the header can be passed and used as a form of authentication. Authentication is also managed in the 3rd example when using -u user:pass. However Jira's REST API does exactly have a REST endpoint that provides the actual attachment itself.

The response shows that we don't have an active session to be able to download that content here.

Please let me know.

Andy

Sergej Grasmik

@JE, @Andy Heinzer

I have to mention, this environment is a Jira Software Server, not Cloud Premium.

100%

Andy Heinzer

Hi everyone,

Andy

jean.dahan

Thank you for opening the suggestion ticket. With regard to using cookie-based auth, I can make a session with a first request like this ..

curl --cookie-jar tmp2.cj -u `cat pass` -o k https://jira.labs.hosting.COMPANY.net/rest/api/latest/issue/ASRDP-1511

.. then we can use the session cookie to get the attachment as follows:

curl --cookie tmp2.cj -o k.zip https://jira.labs.hosting.COMPANY.net/secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip

But if the session cookie is created using a initial PAT based login, like so ..

curl --cookie-jar tmp.cj -o k -H "Authorization: Bearer XXX" https://jira.labs.hosting.COMPANY.net/rest/api/latest/issue/ASRDP-1511

.. and this session cookie is used in a subsequent request, then, again it fails.

curl --cookie tmp.cj --verbose -H "Authorization: Bearer XXX" -o k.zip https://jira.labs.hosting.COMPANY.net/secure/attachment/556907/ce64f351-37fd-4e44-8d63-6fdc27faba88.zip

So it seems the PAT created session is not a session is the fullest sense.

I have not studied other APIs (python jira) or authentication methods like Oauth, but I assume there are no work-arounds there as you have indicated.

Shane K

I am having a similar experience. If I get a cookie by passing in the user/pass to the cookie-based authentication request as the example in the link provided, that cookie can be used for subsequent requests.

If I get a cookie by using bearer authentication with a personal access token I get a successful response and a cookie, but that resulting cookie doesn't seem to work on a subsequent request.

Covance Genomics Lab System Support

For Jira Server 8.20.7, this works for us to retrieve attachments:

curl -L --user joeshmoe:$PASSWORD http://our-jira-hostname/secure/attachment/385/something.docx

Covance Genomics Lab System Support

For JIRA Server 8.20.7, this works for us to retrieve attachments:

curl -L --user joeshmoe:$PASSWORD http://our-jira-hostname/secure/attachment/385/something.docx

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud