Using WGET or another method to download Bamboo shared artifacts (6.10.4+)

[timofey_shklyarov]

https://confluence.atlassian.com/bamboo/personal-access-tokens-976779873.html

https://community.atlassian.com/t5/Bamboo-questions/Re-Using-WGET-or-another-method-to-download-Bamboo-artif/qaq-p/1256940/comment-id/26919#M26919 

After upgrading to 6.10.4 - not able to download shared artifacts using curl any more.

Previously used -u user:password. Now it stopped working, though no notification about it in Bamboo KB..

Tried using save-cookies method and token as well..

curl -v -H "Authorization: Bearer XXXXXXXXXXXXXXXX" https://bamboo.domain.com/artifact/HTMLAI-HAI1401/shared/build-204/htmlai.war/htmlai.war 
...
> GET /artifact/HTMLAI-HAI1401/shared/build-204/htmlai.war/htmlai.war HTTP/1.1 
> Host: bamboo.domain.com 
> User-Agent: curl/7.66.0 
> Accept: */* 
> Authorization: Bearer XXXXXXXXXXXXXXXXXXXXX 
> 
* Mark bundle as not supporting multiuse 
< HTTP/1.1 302 
< X-ASEN: SEN-11111
< X-Frame-Options: SAMEORIGIN 
< X-Content-Type-Options: nosniff 
< Location: https://bamboo.domain.com/userlogin!doDefault.action?os_destination=%2Fartifact%2FHTMLAI-HAI1401%2Fshared%2Fbuild-204%2Fhtmlai.war%2Fhtmlai.war 


curl -v -u 'user:password' https://bamboo.domain.com/artifact/HTMLAI-HAI1401/shared/build-204/htmlai.war/htmlai.war 
...
* Server auth using Basic with user 'user' 
> GET /artifact/HTMLAI-HAI1401/shared/build-204/htmlai.war/htmlai.war HTTP/1.1 
> Host: bamboo.domain.com 
> Authorization: Basic XXXXXXXXXXXX
> User-Agent: curl/7.66.0 
> Accept: */* 
> 
* Mark bundle as not supporting multiuse 
< HTTP/1.1 401 
< X-ASEN: SEN-111111
< X-Frame-Options: SAMEORIGIN 
< X-Content-Type-Options: nosniff 
< X-Seraph-LoginReason: AUTHENTICATION_DENIED 

Any suggestions?

[Daniel Santos]

Hi @timofey_shklyarov

Thank you for all the details shared. They are very helpful!

Accessing with user and password (plain text credentials)

According to my tests, on Bamboo 6.10.4, I get the 401 error when using the wrong credentials (incorrect user or password). The reason for your error could be the same or even a different one.

I get the 403 error when the permissions are incorrectly set to allow plan access. Either the user does not have access to the instance through global permissions (could be logged in user's permission) or he does not have access to the project or plan affected.

What I want to say with the above sentences is that I was able to successfully use the old authentication method to download the artifact with curl.

Accessing with a personal access token

I was not able to download the artifact using this method. I just registered a bug about this since I get a successful code when running the curl command but I don't get any file stream.

This is the bug I just opened:

• [BAM-20764] Attempting to download an artifact using "curl + personal access token" returns nothing and the command succeeds

Next steps

• Can you double-check if you are able to access the artifact through the UI using that pair of user credentials?
• If you can access that through the UI, would you be able to try running the curl command from the server terminal using its IP to check if it will work when the request comes from the same IP of the server?

I'll wait for your next comments.

[timofey_shklyarov]

Thx Daniel for confirming it should still work!

The restapi user had dollar sign in the password and I couldn't get it working via bash: both -u 'user:pas$word' and -u 'user:pas\$word' didn't work, though previously it was (with \). Seems, it has changed since the Bamboo update.

I changed the password, so that it wouldn't have dollar sign and have it working back!

[Daniel Santos]

Hi @timofey_shklyarov

That is really strange. I just ran a test with the in Bamboo 6.10.4 and I was able to get the rest API running with curl just fine.

I created a user called the user with the password pas$word and surrounded those with single quotes.

curl -X GET '<BAMBOO_URL>/browse/<BUILD-KEY>/artifact/shared/artifact/<FILE>' -u 'user:pas$word' 

Possible reasons for the failure:

• Wrong password typed
• Login needing captcha
• Proxy translating the characters and causing trouble
• Terminal evaluation of single quotes before the command is run
• ... something else I was not able to grasp ...

If you want to test this again with a new password including $, please let me know.

[timofey_shklyarov]

yes, when I logged in manually, it was asking for captcha

can u pls inform, what's the preconditions for captcha appearing ? 

my TESTCASE:

1. try REST. it fails

2. log in via GUI. first login fails (though I was copypasting creds, couldn't be wrong). next - with captcha successful.

3. try REST again. Fails again..

JFYI for me. anyway no issues now..

[Daniel Santos]

Hi @timofey_shklyarov

The definitions for captcha are set in Admin >> Security Settings >> Enable brute force protection option.

Usually, this number is configured to 3 attempts. Please make sure you don't have any other process/script attempting to use rest API with this user. It could cause the captcha to be triggered apparently too soon.

• Can you share what is the OS and terminal interpreter used?
• Is the last comment a result of a new test or a recall from the old event?

[timofey_shklyarov]

• tested it on Fedora31 + bash5
• last comment was a recall

No issues now. Thanks for the explanation and help!

[Daniel Santos]

Awesome! I'm happy that we could clarify this together!
I hope you enjoy Bamboo now without issues.

Have a good one mate =]