Like most others in this thread, I am getting constant 410 errors citing the deprecation of app passwords. The documented solution does not resolve the issue, even if I add all available scopes to the API token, even after removing all other credentials through Windows Credentials Manager, even after restarting Bitbucket and rebooting my work machine entirely.
These constant brownouts with no working solution have left our development in a lurch for large swaths of our workdays. Hopefully a viable solution is found as soon as possible...
This has definitely been a block for us, when all we want to do is get things done. Seems like barely any testing was done before tossing it over to actual users.
I've managed to get the API Tokens working on Windows with the latest version of SourceTree.
For me the issue was that SourceTree isn't using the stored Windows Credentials, it was using a cached version of my old credentials which was being controlled by the Embedded Version of Git which SourceTree was using because I have the default "Allow Sourcetree to manage my credentials via the Git Credential Manager" checked.
After upgrading the Embedded Git Version, then choose "Manager" to from a prompt, then when doing a fetch on my repo was prompted to login. I now had a much more modern looking login prompt. And tried the API Token option. It worked, but had to renter the token into the password on every fetch. So, tried the OAUTH option, used my email/api token, and it worked. Rebooted, and on a different day and its still working...
Maybe I could of unchecked the "Allow Sourcetree to manage my credentials via the Git Credential Manager", but I think this might be the cause of the errors for most.
@Richard Brookes-Tee Thanks for the advice, updating the embedded Git version helped me get past the 410 errors when they started up again this morning. I kept the "Allow Sourcetree to manage my creds..." checkbox checked, and I made sure to set my API token as the default method in the Authentication tab. After that I fetched, and I got the prompts you mentioned with the modern authentication flow. Not sure if my authentication will persist, but having to authenticate multiple times is much better than not being able to access source control for hours at a time.
I found out about this through our AI agent when I was puzzled for days about why my commits were suddenly being refused half the time. The way you guys went about this by quietly pushing a blog post (no email? really??) was just about the worst possible way you could have handled this change.
Also was it really necessary to give us all this busywork of faffing around with API tokens (which don't work by the way, if you're reading this and trying to solve your authentication with that, don't bother and just use the ssh authentication key approach instead. I can support anyone who's having trouble with that (unlike Atlassian who seem to think you can swivel if you're struggling apparently).
@Harry Welchman I got the API Tokens working. I agree the communication on this was really bad and was confused why it worked and stopped working. The API Tokens by themselves via curl work fine and others say they also work fine with other git clients they are using, so for me at least the issue was SourceTree.
From what I can see the main issue is the way git caches the credentials and not the Windows Credential Manager that the articles suggest we clear.
With my SourceTree, after a lot of faffing, I figured out all I needed to do was upgrade the Embedded Git Version. Perhaps this forced a clearing of the cached git credentials or it upgraded the binaries sufficiently that they now work with API Tokens. Whichever, in the end it was a simple fix. The thought of creating an ssh key and changing 50+ repos to use it, to me seems like a much bigger faff.
@Richard Brookes-Tee I see, the ssh key approach was convenient enough for me as we are a smaller company that uses not many repos. I'll suggest your method to the rest of the team if they want to use the tokens instead
33 comments