app password warnings after updating Bitbucket account in SourceTree to use an API token

[TomCatchesides]

I'm using SourceTree 4.2.18 on macOS.

Following the warnings about app passwords being deprecated, I've created an API token and edited my Bitbucket account within SourceTree to use the API token (following these instructions). All of my repositories are within this single Bitbucket account and I don't have any other accounts set up in SourceTree.

When I try to push a commit from SourceTree to my git repositories on Bitbucket, I'm still getting periodic "CHANGE-3222 - Functionality has been deprecated" errors. I get the same error if I try to clone one of my remote repositories.

How do I go about making SourceTree work with API tokens?

[Mommens]

For those who still have the issue this worked for us : 

Add the API_token in the url ( This is very unsafe i know )

https://{bitbucket_username}:{API_token}@bitbucket.org/{workspace}/{repository}.git

Try to push something and you will see this error 

remote: You may not have access to this repository or it no longer exists in this workspace. If you think this repository exists and you have access, make sure you are authenticated.

Remove the API_token from the url again and try pushing again. This worked for all our repos ...

This entire API_token approach feels highly unstable at the moment ! We hope they fix it soon, and we hope the above might help some of you !

[TomCatchesides]

Thanks for sharing an approach that worked for you! As you say, including the API token in the URL feels very unsafe, which makes Atlassian forcing us to do this feel very counterproductive. 

I'm going to hang on for another solution, even if that means moving to a different host for our repositories.

[Mommens]

Yep it's unsafe but just add it try to push once, remove it restart Sourcetree and for me the problem goes away

[Joas de Haan]

Adding the api_token in the url works for me also. I added it once, pushed successfully, then removed it again and it has worked for a couple of pushes and fetches now, even without restarting Sourcetree.

[Kegan Huntley]

thanks Mommens for the solution, its ridiculous how they just make things worse and worse uuggh so annoying

[Richard Brookes-Tee]

Annoyingly, I've been getting this whenever there was a brownout and fingers crossed seemed to have resolved it, at least for now, will have to try tomorrow and in a few days to make sure its still working.

I'm running the latest version of SourceTree 3.4.31 on Windows 11.  During the brownouts I was seeing the App Passwords Deprecation message, so I tried following the instructions on the blog post saying to delete from windows credentials and sourcetree and readd the account with the API Token as the password.  This didn't work and during the brownout kept failing.

I then decided to go to my Bitbucket account and revoke the APP Passwords.  This didn't work.

I tried the Api Token in a curl command, and that worked.

curl -u your-email@example.com:YOUR_API_TOKEN https://api.bitbucket.org/2.0/repositories/YOUR_WORKSPACE/YOUR_REPO

So, knew it had to be something in SourceTree so started digging.

In the Options -> Tools -> Git, theres an option to Allow Sourcetree to manage my credentials via the Git Credential Manager.  For me this was ticked.  I tried unticking, made no difference, so I reticked it.

Further down in Options -> Tools -> Git theres a UI to choose which version of Git to Use (Embedded/System) and also Update Embedded.  My was set to Embedded and was showing 2.2x.x, if I clicked System it showed 2.34.1, so I decided to Update Embedded.

Eventually this through up a prompt asking me to choose which Credential Manager I wanted to use.  I choose "Manager" as the others, seemed to be deprecated windows versions, I also made multiples of everything showing, so just picked he bottom one "Manager".

Then Ensured (again) all bitbucket windows credentials and accounts in bitbucket were removed.  Restarted sourcetree.  Then fetched my repo and now I see a different UI asking for password / token that I'd never seen before.  Much more modern.

I tried the right hand option that was labeled API Token, put in my email and api token and it worked, but then I tried fetching and it asked again and again.  so i then tried the web login option, and put in my email and api token and it worked and seems to be working now after multiple fetches and trying other repos.

So, I'm not sure if this is the issue, outdated git tools Embedded in SourceTree (I only updated it a few weeks ago), or its the Git Credentials Manager being used by the Embedded version of Git (and me updating flushed it), but it seems to have worked for me. 

[Richard Brookes-Tee]

onto a new day and its still working for me

[Richard Brookes-Tee]

day 3, still working

[NLeather1]

Thank you - updating the embedded git also changed my prompts - the only thing that has given some success.  Changed the embedded version in Tools | Options - go to "Git" tab, scroll to bottom and click "Update Embeded". Now on cloning or pushing I get a new popup like you where I confirm "manager" as the choice and everthing then works.  Not sure if I have re do credentials on every repo yet - time will tell

[lcapozzi]

Found a workaround. Manually editing the remote and changing it to:
git@bitbucket.org:{username}/{repo}.git works without any issues. Now I only have to update around 100 entries...

[TomCatchesides]

I'm glad you've got yours working!

The remote URLs I have in SourceTree are of the form https://{username}@Bitbucket.org/{username}/{repo}.git so are you saying that I should change that to https://git@bitbucket.org/{username}/{repo}.git ?

If so, that doesn't work for me: I get this password dialog and authentication errors.

[lcapozzi]

remove https://. It should start with git@bitbucket.org.

[TomCatchesides]

Thanks, @lcapozzi 

git@bitbucket.org/{username}/{repo}.git is giving me the following error (although obviously with my values for username and repo name):

fatal: 'git@bitbucket.org/{username}/{repo}.git' does not appear to be a git repository

fatal: Could not read from remote repository.

[lcapozzi]

I worked on our repos all day and right now, all of a sudden, the git@bitbucket.org method is not working any longer. It say I don't have permissions. WTF?

git@bitbucket.org: Permission denied (publickey).

This must be a joke

EDIT: That's not even working using other clients (Fork), so maybe this endpoint has been blocked today? Can Atlassian give some answer?

Speaking about answers... I also issued a ticket for this issue and I've been replied that (As a paid customer) my level of support is the community. Congratulations. 

[Tomislav Tobijas]

@Ben can you, or maybe someone else from the Bitbucket team, provide some insights here? (or potentially create a ticket) 👀

[lcapozzi]

Update: after being able to, at least, see my remote repo list I tried swapping the current repo's remote while selecting it again from the list and now it seems to be working. Hopefully it'll last, so I won't have to manually change over 100 repos 

[TomCatchesides]

Well done, @lcapozzi 

Can I ask what your steps to resolve this were in the end? And is the solution working during one of the scheduled brownout periods?

[lcapozzi]

- Removed all stored credentials and ssh keys

- Removed the account

- Remade the account with the API token

- Open any repo and do any git operation. It'll prompt for a password

- Type your Bitbucket account password

- Edit the origin and click on the hosted projects, so a list of remote repos will pop out

- Select your repo and save

[lcapozzi]

A little update: now SourceTree crashes every time I push or pull a commit. Way to go!

[Tomislav Tobijas]

I’ve created a bug on Atlassian’s public tracker so the Sourcetree team can investigate it further: https://jira.atlassian.com/browse/SRCTREE-8274

Feel free to watch and vote for the issue, and add any additional details or examples that might help with the investigation.

In case support asks for additional information, I'll forward it here.

[Colpocorto]

All the suggested workarounds worked for just 1 or 2 days. Then the error appears again.

And, without any additional change, if I wait a couple of hours and try again, it will work. But later on, it throws the same error again.

Honestly, I don't believe this is an actual misconfiguration or authentication issue. I think it's a random, uncontrolled bug at the Atlassian side of things.

[TomCatchesides]

FWIW, the Fork git client seems to work well with Atlassian's API tokens, at least on macOS. It's been working for me for four days now.

[Colpocorto]

Nah, I like SourceTree and it's free.

I'll wait one more week. If the issue hasn't been fixed, will migrate everything to Gitlab. Sadly, I love the integration with Jira and Confluence, but if Atlassian pushes me towards other Git service, I will move on.

[TomCatchesides]

For what it's worth, I think I've verified that the Fork git client works well with Atlassian's new API token requirement for Bitbucket.

On my Mac, I've been using Fork with my existing repositories and set up my Bitbucket account using the API token that Sourcetree was struggling with. It seems to have been working well during the latest brownout period.

This reduces the urgency of moving away from Bitbucket, although I'm still tempted to do so after this recent experience.

[lcapozzi]

I think the main issue here is that the client is still looking for ssh credentials despite we chosen the API Token. I'm now trying to get another one of our Mac to get back to work and the struggle is real. For example: I've removed all saved credentials, edited the config and well-known hosts ssh files and also removed the account from SourceTree. After that, even restarting SourceTree and doing any git operation results in the client looking for the app password. 

[lcapozzi]

We have the same issue. We've been force to move to API Tokens, but the SourceTree client is not working any longer on some machines. With the same API Token and same credentials we don't have the same results. If we switch to another client (for example, Fork) everything works as expected. We cleared the stored Keychain entries, but that hasn't helped. We are basically locked out our entire codebase. Please, fix this asap!

[TomCatchesides]

@lcapozzi I'm glad I'm not the only one, but you'd expect Sourcetree to work with Atlassian's mandated changes wouldn't you?

[lcapozzi]

absolutely. Considering that I'm also on a paid account, it's utter nonsense that I'm unable to chat with a human being via the support page. I'm seriously considering migration to another platform. 

[Tomislav Tobijas]

Hey @TomCatchesides ,

Have you tried clearing the macOS keychain? It should be something like Keychain Access 👀
I don't have Mac, but I know that a similar thing sometimes needs to be done on Windows in Credential Manager. 

In Mac, it's something like:

1. Open Keychain Access on your Mac.

2. Search for bitbucket.org.

3. Delete any entries related to your Bitbucket account.

4. Restart Sourcetree and perform a Git action; it should prompt you for your credentials, where you can enter your email and API token

Potentially Sourcetree cached old credentials in the local repo config. You could open repo in Sourcetree > Settings (top right) > Remotes and check the origin remote. (select 'edit')

Cheers,
Tobi

[TomCatchesides]

Thanks for the suggestion @Tomislav Tobijas! I've tried what you've suggested and got SourceTree into even more of a mess now…

1. Deleted Bitbucket entries from KeyChain access.
2. Relaunched SourceTree.
3. Edit account: the API token has been cleared, so I reenter it and click Save.
4. A dialog window appears, asking for a password (see first screenshot). I enter my Bitbucket account password.
5. When I try to pull from one of the remotes in this account, I'm asked for a password again (second screenshot). I've tried entering my account password or the API token and in both cases I get the following error:
   

   remote: You may not have access to this repository or it no longer exists in this workspace. If you think this repository exists and you have access, make sure you are authenticated.
   
   fatal: Authentication failed for 'https://bitbucket.org/…/'

Editing the account and changing back to basic auth with the app password that I was previously using resolves this, but that is of course going away soon.

[lcapozzi]

I'm on the same identical situation. I've also cleared the stored SSH credentials... everything. 

[Tiago_Lira]

Having the same issue. 
Changed bitbucket auth to use API token, sourceTree still gives me the same "App Passwords" error.

[TomCatchesides]

@Tiago_Lira Yeah, there seem to be a few of us affected by this. I hope that we find a solution before I'm forced to move to a new host for my repositories.

[Joseph Rivera]

@TomCatchesides Well that was a frustrating experience, but I was in the same predicament with SourceTree thinking the repository doesn't exist for some reason. What ended up working for me was removing all bitbucket and SourceTree credentials from my Windows credential manager, then changing the Remote Repository URL in my SourceTree repository settings.

Previously it had:

'https://{Username}@bitbucket.org/...'

I had changed this to:

'https://x-bitbucket-api-token-auth:{APIToken}@bitbucket.org/...'

Apparently this is one way to kind of force SourceTree into communicating with Bitbucket using the generated API token instead of trying to utilize previously stored credentials. The only downside with this is it can store the API token in plain text, but since I'm the only one who ever uses my computer, it's not really a concern for me.

[Mommens]

I've done something similar ( answered above )

Putting the APIToken in the url like that is very unsafe, anyone looking at the network traffic can just pluck it off ... 

[james]

This is starting to become very time consuming, and I am crossing the threshold where I am going to give up with Bitbucket and invest my time migrating to Github instead. 

I have 2 machine side by side. One of them is working. When I replicate the settings IDENTICALLY in the Sourcetree UI, I get the error message.

For me, this rollout has been totally botched - Sourcetree is an Atlassian product. It should just work. 
Am starting to wonder why I am using Bitbucket - API Keys from Github just work in Bitbucket. I haven't had a single problem. Why is this so difficult Atlassian????

[james]

The only way I could get it working on the second machine is using Joseph Rivera technique: 
'https://x-bitbucket-api-token-auth:{APIToken}@bitbucket.org/...'


but this is useless to me because I have over 50 Bitbucket repos configured, so I do not want to have to spread my API Key in the URL for all these repos.

[TomCatchesides]

Thanks to @Joseph Rivera and everyone else who's suggested the https://x-bitbucket-api-token-auth:{APIToken}@bitbucket.org/... approach, but including our API token in a URL feels like a very bad idea.

Unfortunately, I think I agree with @james that it's probably better for me to spend the time that I'm likely to need to resolve this issue with Bitbucket and Sourcetree on migrating to a different host.