Issue #15196 open
Stuart Auld created an issue

According to https://github.com/terraform-providers/terraform-provider-bitbucket/pull/9 you're planning on removing the 1.0 APIs. Given that many of these features are not available via the 2.0 API, can you confirm this and provide a timeline?

Comments (28)

  1. Erik van Zijst

    you're planning on removing the 1.0 APIs. Given that many of these features are not available via the 2.0 API, can you confirm this and provide a timeline?

    We are not retiring a lot. The APIs in question are exclusively those that are used to create credentials (API Keys, OAuth Consumers, Deploy Keys) programmatically.

    Bitbucket's plugin system is centered around addon/apps that get installed into (team) accounts that can then augment the UI with custom pages, widgets, etc and make authenticated API calls that mutate repos. Upon installation the user has to explicitly accept the permissions the addon is requesting.

    Now when an addon gets uninstalled, we revoke the addon's credentials, but we want to make sure that all access is properly revoked and the addon can no longer access any of the team's data. This can be tricky if an addon can create new credentials while installed. We want to avoid a scenario where an addon gets uninstalled, but it effectively retains access through custom deploy keys it uploaded, unbeknownst to its users.

    The same applies to the OAuth consumer API which is planned to be retired as well. Similarly, we are not planning to create an API that allows external apps to programmatically create App Passwords.

    We communicate timelines around the end-of-life of features at https://confluence.atlassian.com/bitbucket/end-of-support-announcements-for-bitbucket-cloud-833985475.html

  2. Joel Courtney

    Just like to register disappointment on this:

    Similarly, we are not planning to create an API that allows external apps to programmatically create App Passwords
    

    The lack of tracking of the originating entity for a key is surely the issue at play here. The revocation of an application or user access should revoke or offer the transition of the keys associated with that entity to another entity as an alternate solution to the problem rather than brute force blocking.

    While BitBucket may have built their plugin system around UI niceties, plenty of powerful additions can (and should) be made by non-UI based enhancements. It's sad that this is not identified and supported as the leading competitor, Github, is far more advanced in supporting programmatic interfaces (ref: https://developer.github.com/v3/ esp https://developer.github.com/v3/repos/keys/ ).

  3. Stuart Auld reporter

    Yeah I think the word “exclusively” may have been overkill in your response. It seems like you’re removing pretty much all the features I care about, namely the ability to programatically control access to Bitbucket. If we can’t create users and groups via the API, how can we properly manage them?

  4. Darren Harrison

    I agree with Stuart Auld, all the features I care about have been removed. We use Bitbucket as one of our development tools and I want to automate adding/deleting users and adding/removing them from groups.
    As with any software, I'm sure there are some very real reasons why this hasn't been done and it's probably all pretty complex, but the request to be able to do this shouldn't be a surprise, it's a very common thing that most API's I use are able to do.

  5. Sebastiaan Candel

    +1. I can not understand why you deprecate an API in favour of a new 2.0 API, when this new API does not even cover any existing functionality on user group membership. Your UI is severely lacking (non-existant) for managing multiple users and their membership and permissions.

  6. James Jones

    +1 Please reconsider this decision. If we can't manage access with the API there's hardly any point having it at all. Finding out about this has got me scrambling to find a new home for my repositories.

  7. Rich Glazier

    I agree. Any update on 2.0 API user/group control functionality in BB? Don't mean to pile on, but yeah, I would advise against killing an old API, until it's core functionality is replicated in the new one (and I consider this 'core'). Are we waiting on a secure way to add/remove users/groups in 2.0, or is it never going to be implimented?

  8. Marc Parnell

    +1 I'd also like to strongly agree. API 2.0 takes away the group and repo management that we need, and renders BitBucket useless for us.

  9. Joel Courtney

    Given the issues highlighted are coming up on a year old, is Bitbucket or Atlassian in a position to provide commentary?

  10. Michael Pistrang

    Requiring the management of group access to repositories to be manual process only will result in human error and skipped off-boarding steps due to how tedious it is. Reinstate the API for this to help with security!

  11. Vincent Ordioni

    +1, any news on the users/group access API on 2.0?
    A word form Atlassian on the subject would be great, just give us a definitive answer, is there gonna be one or not?
    If yes, can you give us an approximative ETA?
    If no, can you tell us why?
    Bitbucket is an awesome platform but without this kind of features, we will have to find another one, and that is not what any of us want I am sure.

  12. Akshay Philar

    +1 for users/group access on API V2.0 This is absolutely essential for our workflow, failing which we will need to think about migrating elsewhere.

  13. Oz Linden

    We currently synchronize our BitBucket team groups with our internal user data by using these 1.0 apis:

    • We use GET to this to determine the groups defined for the team

      /api/1.0/groups/<team>/

    • We use GET to this to determine the current members of the group

      /api/1.0/groups/<team>/<group>/members

    • We use PUT to this to add a user to the group and DELETE to remove them

      /api/1.0/groups/<team>/<group>/members/<user>

    The interfaces above are the single most important reason we use bitbucket rather than github.

    We also use

    /api/1.0/privileges/<repo>
    /api/1.0/group-privileges/<repo>
    

    to validate the access to repositories; these are also important, but slightly less so that groups.

  14. Andrew Baxter

    So FWIW the 1.0 API appears to still be working despite the removal notice, at least of today.

  15. Log in to comment