Uploaded image for project: 'Bitbucket Cloud'
  1. Bitbucket Cloud
  2. BCLOUD-8542

Determine whether authenticated user has "write" access to a repository? (BB-9628)

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      If I'm not mistaken, there's currently no way to determine whether the authenticated user has write access to a specific repository using the Bitbucket API.

      I know it is possible to determine whether it has "admin" access using the "privileges" resource. Similar goes for "read" access. Nonetheless determining if the user has "write" access is not possible without trying to actually write to the repository.

      But determining "write"/"admin" access in advance is crucial for any serious application built upon the API.

      My proposal is simply adapting following resource: https://confluence.atlassian.com/display/BITBUCKET/privileges+Endpoint#privilegesEndpoint-GETprivilegesforanindividual\\
      It is currently restricted to: "only the repository owner, a team account administrator, or an account with administrative rights on the repository can make this call."

      Making this resource available to the user that is being queried (so the authenticated user can query this resource about himself for every repository) would solve the whole problematic, providing a clean way of determining the access level to a repository.

            [BCLOUD-8542] Determine whether authenticated user has "write" access to a repository? (BB-9628)

            Atlassian Update - August 2, 2021

            Hi everyone,

            Thank you for bringing this suggestion to our attention.

            As explained in our new feature policy, there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritize and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order.

            Unfortunately, as a result of inactivity (no votes or comments for an extended period of time), this suggestion didn’t make it to the roadmap and we are closing it.

            While this issue has been closed, our Product Managers continue to look at requests in https://jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket.

            Thank you again for providing valuable feedback to our team!

            Matthew Hunter added a comment - Atlassian Update - August 2, 2021 Hi everyone, Thank you for bringing this suggestion to our attention. As explained in our new feature policy , there are many factors that influence our product roadmaps and determine the features we implement. When making decisions about what to prioritize and work on, we combine your feedback and suggestions with insights from our support teams, product analytics, research findings, and more. This information, combined with our medium- and long-term product and platform vision, determines what we implement and its priority order. Unfortunately, as a result of inactivity (no votes or comments for an extended period of time), this suggestion didn’t make it to the roadmap and we are closing it. While this issue has been closed, our Product Managers continue to look at requests in https://jira.atlassian.com as they develop their roadmap, including closed ones. In addition, if you feel like this suggestion is still important to your team please let us know by commenting on this ticket. Thank you again for providing valuable feedback to our team!

            enji_bkk added a comment -

            On our private server I no not have access to the 2.0 APIs nor to the 1.0 privileges end points. I came up with another workaround (windows CMD commands)

            curl -s -u %USER%:%PASSWORD% "https://my.server.url/rest/api/1.0/users?filter=%USER%&permission=REPO_WRITE&permission.projectKey=%PROJECT%&permission.repositorySlug=%REPOSITORY%" -w "\n%{http_code}\n" 
            
            • If user/password is not valid, I get an HTTP 401
            • If user/password is valid, and user has REPO_WRITE access, I get HTTP 200, with content:
            {"size":1,"limit":25,"isLastPage":true,"values":[{"name":"my-user-name","emailAddress":"","id":69073,"displayName":"my-user-name","active":true,"slug":"my-user-name","type":"NORMAL","links":{"self":[{"href":"https://my.server.url/users/my-user-name"}]}}],"start":0}
            
            • if user/password is valid, but user does NOT have REPO_WRITE access I get HTTP 200 and
            {"size":0,"limit":25,"isLastPage":true,"values":[],"start":0}
            

            This is giving the result I expect (success if REPO_WRITE is granted at either repository or project level, failure otherwise)

            (N.B.: in case I have a user whose name would match /my-user-name.*/, having REPO_WRITE permission, he would be returned too. The result should be parsed to find if one of the returned users is as exact match)

            enji_bkk added a comment - On our private server I no not have access to the 2.0 APIs nor to the 1.0 privileges end points. I came up with another workaround (windows CMD commands) curl -s -u %USER%:%PASSWORD% "https: //my.server.url/ rest /api/1.0/users?filter=%USER%&permission=REPO_WRITE&permission.projectKey=%PROJECT%&permission.repositorySlug=%REPOSITORY%" -w "\n%{http_code}\n" If user/password is not valid, I get an HTTP 401 If user/password is valid, and user has REPO_WRITE access, I get HTTP 200, with content: { "size" :1, "limit" :25, "isLastPage" : true , "values" :[{ "name" : "my-user-name" , "emailAddress" : ""," id ":69073," displayName ":" my-user-name "," active ": true ," slug ":" my-user-name "," type ":" NORMAL "," links ":{" self ":[{" href ":" https: //my.server.url/users/my-user-name "}]}}]," start":0} if user/password is valid, but user does NOT have REPO_WRITE access I get HTTP 200 and { "size" :0, "limit" :25, "isLastPage" : true , "values" :[], "start" :0} This is giving the result I expect (success if REPO_WRITE is granted at either repository or project level, failure otherwise) (N.B.: in case I have a user whose name would match /my-user-name.*/, having REPO_WRITE permission, he would be returned too. The result should be parsed to find if one of the returned users is as exact match)

            Thanks for the reply, Erik. That workaround works for me.

            Legacy Bitbucket Cloud User (Inactive) added a comment - Thanks for the reply, Erik. That workaround works for me.

            evzijst added a comment -

            I'm afraid it is not currently being worked on, but there is somewhat of a workaround.

            The 2.0 repositories API supports a role parameter that is used to filter a result set down according to the privileges the authenticated user has on them. For instance, to retrieve all of team "foo"'s repositories that the authenticated user can write to, hit:

            :::text
            GET /2.0/repositories/{username}?role=contributor
            

            evzijst added a comment - I'm afraid it is not currently being worked on, but there is somewhat of a workaround. The 2.0 repositories API supports a role parameter that is used to filter a result set down according to the privileges the authenticated user has on them. For instance, to retrieve all of team "foo"'s repositories that the authenticated user can write to, hit: :::text GET /2.0/repositories/{username}?role=contributor

            Hi,

            I just stumbled upon this issue because I have the same problem as the original poster: determining whether the currently authenticated user has read and/or write access to a specific repository.

            Seeing that the issue is nearly two years old, I'd like to ask whether this is still being worked on, or maybe if there's a solution by now that I have missed?

            Best,
            Philipp

            Legacy Bitbucket Cloud User (Inactive) added a comment - Hi, I just stumbled upon this issue because I have the same problem as the original poster: determining whether the currently authenticated user has read and/or write access to a specific repository. Seeing that the issue is nearly two years old, I'd like to ask whether this is still being worked on, or maybe if there's a solution by now that I have missed? Best, Philipp

            evzijst added a comment -

            Yep, I agree. I've raised an internal issue for this.

            evzijst added a comment - Yep, I agree. I've raised an internal issue for this.

              Unassigned Unassigned
              legacy-bitbucket-user Legacy Bitbucket Cloud User (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: