Authentication failure when downloading avatar.png

• Jenkins version 2.222.3
• Plugin version 2.8.0
• Bitbucket server 6.7

Description

We are seeing intermittent failures when avatar.png is attempted to be obtained from BitBucket server when using combination of <username>:<personal access token> as credential set. Why intermittent? As we see that it is happens not consistently while we are not changing the credentials for the configured projects.

2020-06-21 09:13:35.313+0000 [id=657237]	INFO	c.c.j.p.b.BitbucketTeamMetadataAction$BitbucketAvatarCacheSource#fetch: IOException: I/O error when accessing URL: /rest/api/1.0/projects/ACME/avatar.png
com.cloudbees.jenkins.plugins.bitbucket.api.BitbucketRequestException: HTTP request error. Status: 401: .
HttpResponseProxy{HTTP/1.1 401  [X-AREQUESTID: *1M4EBR5x553x10156594x4, X-ASEN: SEN-8840825, WWW-Authenticate: Basic realm="Atlassian Bitbucket", Content-Type: application/json;charset=UTF-8, Date: Sun, 21 Jun 2020 09:13:30 GMT, Location: , Vary: Accept-Encoding, Connection: Keep-Alive] org.apache.http.client.entity.DecompressingEntity@6f558806}
at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getImageRequest(BitbucketServerAPIClient.java:880)
at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getTeamAvatar(BitbucketServerAPIClient.java:731)
Caused: java.io.IOException: I/O error when accessing URL: /rest/api/1.0/projects/ACME/avatar.png
at com.cloudbees.jenkins.plugins.bitbucket.server.client.BitbucketServerAPIClient.getTeamAvatar(BitbucketServerAPIClient.java:736)
at com.cloudbees.jenkins.plugins.bitbucket.BitbucketTeamMetadataAction$BitbucketAvatarCacheSource.fetch(BitbucketTeamMetadataAction.java:80)
at com.cloudbees.jenkins.plugins.bitbucket.avatars.AvatarCache$FetchImage.call(AvatarCache.java:624)
at com.cloudbees.jenkins.plugins.bitbucket.avatars.AvatarCache$FetchImage.call(AvatarCache.java:612)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Similar issues seems to be raised here: https://issues.jenkins-ci.org/browse/JENKINS-61200

[justinjschaub]

This is still a constant pain. Would love to see the proposed change get merged in.

[Cyanoth]

We have recently been impacted by this issue after changing the password to a number of accounts; Since the avatar is refreshed periodically & each time it is using the wrong credentials, it eventually it causes a captcha.

Taking a look, when credentials are used on a Bitbucket Team/Project item, the BitbucketAvatarCacheSource configuration gets serialized including the credential it used & stored in JENKINS_HOME/jobs/JOB_NAME/state.xml. This includes the ID & the value of the credential.

So when the credential is updated in the credential store, the BitbucketAvatarCacheSource continues to use the old value from the serialized copy (again, from JENKINS_HOME/jobs/JOB_NAME/state.xml). So as the credential in state.xml is out-of-date, requests to fetch the avatar fail with 401 - Invalid Credentials and serveral of these in a row, cause a captcha.

As a workaround: Create a new credential with valid a username & password/token. It must have a different ID to the originally selected ID. On the bitbucket team/project, change the credential to the new credential. This will refresh the state.xml with the new value of the credential. Optionally, you can change switch back to the old credential id now & delete the newly created one.

Importantly:

• The new credential ID must be different for it to refresh the value stored in state.xml; Simply re-saving or changing credential from one to another doesn’t work.
• The new credential must be valid. state.xml only gets update if the new selected credential is valid.

This will fix it until the credential is updated again.

I’ve been looking into a more permanent solution; I believe BitbucketAvatarCacheSource shouldn’t use a serialized copy of the credential, instead store the ID of the selected credential & fetch it from the credential store. This is what I’ve been looking at this afternoon and got a solution working if the credentials are scoped globally. But not when credentials are in a different scope (like the team folder) - and this is likely why the credential has been serialized in the first-place.

Hoping to have a further look into the issue & getting it to work with any scope credentials.