Changes to BitBucket API impacts Composer installation

Issue #15014 resolved
Klaas Sangers
created an issue

A short while ago the BitBucket API changed the clone URL it returns from git@bitbucket.org to <account/team>@bitbucket.org. This impacted our private Composer hosting (Satis-based) because of the following:

  • The API returns the team name as the user for cloning (e.g. team@bitbucket.org/team/repository.git)
  • Developers attached to the team do not have access to the team user clone URL (e.g. user called 'developer', who has read/write/admin access to the team called 'team', cannot clone any repository from team@bitbucket.org/team/repository.git)
  • Composer projects would get developer@bitbucket.org/team/* URLs in the composer.lock file, developer2 would then get issues as they do not have access to the developer user.

In my opinion it should be possible for team members to clone from team repositories using their own SSH keys on the team user.

Comments (8)

  1. Marcus Bertrand staff

    While I'm not familiar with Composer, I did find some docs that seem to hint that you could use https with Bitbucket's OAuth and things should work. But perhaps I've misread... Can you comment on how https://getcomposer.org/doc/05-repositories.md#using-private-repositories is expecting things to be setup? There's a note a little ways down that says Note that the repository endpoint needs to be https rather than git. which would be true if you use OAuth.

  2. Klaas Sangers reporter

    @Marcus Bertrand Thank you for your feedback. I have tested this and I was able to get OAuth working, as in: I could use my account its OAuth credentials to access repositories of the team (of which I am a member). This change also ensured the composer.lock file does not get 'polluted' by developer usernames. I did find it odd that I needed to configure a Callback URL for the OAuth access (the driver suggested http://example.com, so I used that).

    We will most likely not use the OAuth solution as we already have a functional workaround for the issue (using git@bitbucket.org/team/repository.git, instead of team@bitbucket.org/team/repository.git which our tooling receives from the BitBucket API). Using OAuth would force us to change many systems all of which currently rely on public key authentication.

    If there are plans to allow the same kind of access for authorized members of a team using the team its user for SSH, I would be very interested to get notified about it.

  3. Alastair Wilkes staff

    Hi Klaas,

    The API returns the team name as the user for cloning (e.g. team@bitbucket.org/team/repository.git).

    This is a bug that we will fix imminently - these should be prefixed with git@ as they were previously. When that rolls out, you should/might be able to remove your workaround. Sorry for the inconvenience.

    Edit: I clearly did not have my coffee before writing this. I thought were were talking about HTTPS URLs - which have not changed! At this time we're going to keep them consistent and not change this. Apologies for the mix-up.

    Alastair

  4. Klaas Sangers reporter

    @Alastair Wilkes Hahah, coffee is required for these things! Don't worry about it :) So just to reiterate for people from the future: This issue is regarding the SSH repository URL's which are received from the BitBucket Repository API.

  5. Dieter Blomme

    Why was the URL changed? When we use a repository and use submodules, if we don't change the prefix from username@ to git@, only the user that added the submodule can properly clone. I don't understand why this was changed and can't find any changelog explaining the reason, except in an issue here (https://bitbucket.org/site/master/issues/14985/username-in-ssh-repository-url). I'd expect a setting so you can revert to the old behaviour for an account / organization to avoid people making mistakes. Cause the couple of milliseconds you supposedly save per git operation locally will be lost quite quickly by human errors with this new URL...

  6. Log in to comment