Issue Summary

For projects, when using the API, or when viewing inspecting the object in the UI, the avatar resource link is returned in the following JSON object:

    },
    "html": {
      "href": "https://bitbucket.org/<workspaceID>/workspace/projects/<projectKey>/avatar"
    },

However, this is not the case with repositories' and workspaces' avatars. These resources are available in the following format instead for repositories and workspaces:

    "avatar": {
      "href": "https://bytebucket.org/ravatar/%7B<UUID>%7D"
    },

The impact of this is that, for repositories and workspaces, the avatar image can be viewed publicly, without requiring users to be logged into Bitbucket. This is inconsistent with the behavior of projects, which require the user to be authenticated before redirecting to the appropriate resource in S3.

Steps to Reproduce

There are two ways to reproduce this:
First option:

1. Navigate to any project in the UI;
2. Open the devtools console (F12) and click on the avatar for the project
3. You should see that the reference for the avatar resource is https://bitbucket.org/<workspaceID>/workspace/projects/<projectKey>

Second option:

1. Use the following Bitbucket API endpoint

   https://api.bitbucket.org/2.0/workspaces/{workspace}/projects/{project_key}
   

2. Check the response. The project avatar object will look like this:

       },
       "html": {
         "href": "https://bitbucket.org/<workspaceID>/workspace/projects/<projectKey>/avatar"
       },
   

Expected Results

The Avatar reference to the resource should reference the appropriate bytebucket link in the API and UI, like so:

https://bytebucket.org/ravatar/%7B<UUID>%7D

This will allow users to access the avatar resource without authentication, to be consistent with other endpoints such as repositories and workspaces.

Actual Results

Bitbucket references the following link to redirect to the Avatar resource for projects, both on API and UI:

https://bitbucket.org/<workspaceID>/workspace/projects/<projectKey>/avatar

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available