Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,455,904
Community Members
 
Community Events
176
Community Groups

BUG: Sourcetree app is reliably kicking my app password session

Edited

The new app passwords are not working well at all. The Sourcetree app keeps killing my session on a weekly basis. This never happened with the normal user account passwords.

Please provide a fix for this or tell me how I can make sure the sessions aren't killed every week. I have literally had to create a new app password every single week.

3 answers

1 vote
Mukesh Kumar Atlassian Team Jun 30, 2022

Hello @mai_il_2011 ,

 

Bitbucket does not expire the app password (more info).

However when the user uses the authentication type as Basic, Sourcetree uses the app password created by the user in Bitbucket. Sourcetree stores those credentials through Windows Credential Manager.

Credentials in the Windows Credential Manager can get erased due to following issues:

  • If Git believes the credentials failed to grant proper authorization to do whatever Git was attempting to do, it asks git-credential to erase the stored credentials. The git-credential process then invokes git-credential-manager to delete the stored credentials (more info).
  • Windows Credential Manager loses passwords (more info). Microsoft has provide a fix for this issue (more info).

 

To avoid this issue we strongly recommend using OAuth authentication over Basic authentication (OAuth setup guide). 

OAuth does not use app passwords at all. It is more secure and easy to setup than Basic authentication.

 

Regards,

Mukesh Kumar

Why did Windows not expire the sessions that were created with normal passwords that you forced us to stop using? Can you please explain why we were forced to switch to app passwords if people are going to be told by your support staff via email to just keep the passwords stored in plain text? Why create app passwords if they don't work as YOU indented them to (IE: Have sessions that don't expire)? I was able to use my normal password up until recently and this is honestly the most frustrated I've been in a long time because you refuse to help sort out YOUR BUG. I've been going back and forth with you all for a month now just to essentially be told by you here that "It's not our fault, it's Windows' fault, we recommend you don't use our feature that we forced you to switch to." Do you realize how that sounds to us as users? It's completely illogical. Furthermore, Microsoft's "fix" article you referenced is from 2020, well before you forced us to switch to app passwords. If it's a problem before you force us to switch, I'm sorry, that bug in on YOU. NOT Microsoft. Please provide a viable solution or fix to your product's bug. If credential manager works a certain way, then you adapt. You don't jerk me around for a month after forcing me to start using a feature I never asked for.

This is how Git Credential Manager works:
Git Credential Manager to attempt to authenticate and if due to any reason like internet issues, corporate firewall and policy or anything else if authentication fails then Git Credential Manager deletes the stored credentials. This is independent from Sourcetree.

Below is the link of the same issue where people are talking about same issue and they are using Git by command line not by Sourcetree.
(I have two different build agents, one for production, the other for development. On both boxes, I have Git Credential Manager for Windows installed. Via the git command line, I enter my username and password the first time and the application stores it into Windows Credential Manager for future use. This all works perfectly... except when a few days later the credential disappears from the store and all my processes that depend on that break. I have looked through the event logs, TechNet, this repo, and other various tech forum and I can't find the root cause of this.
It only happens with the Visual Studio Online credential. I also have a bitbucket credential stored and it doesn't have this problem.
Unfortunately, this is inconsistent. Sometimes it will go a week before the credential disappears, sometimes it happens daily.
For now, I've resorted to manually backing up the credential store and then manually restoring it. Is there something broken between this application and VSO that causes this behavior? The documentation specifically states that it was designed to work with build agents and VSO so it seems very unusual for this issue to continually happen.)
Since that issue is not under control of Sourcetree, we recommend using OAuth for authentication.
Regards,
Mukesh Kumar

Can you explain why user passwords worked completely fine? Everything was perfectly fine until you forced us into using app passwords which don't work.

Mukesh Kumar Atlassian Team Jul 15, 2022

Hi @mai_il_2011 


Atlassian account password for Bitbucket API and Git activity has been deprecated to improve Atlassian account security (more info). 

Stored credentials from Windows Credential Manager can be removed due various reasons including corporate policy and firewall. Can you please check with your IT team to understand better on how the app password gets removed?

We would suggest trying to use the OAuth authentication method instead. It's typically much easier to use and it should authenticate you by walking you through the Bitbucket Cloud login screens with your account password (instead of an app password).

 

Regards,

Mukesh Kumar

Like Stephen Sifers likes this

You didn't answer the question at all.... Let me ask it a different way in hopes you answer it this time... Did normal account passwords (which you forced us to stop using) use credential manager in the way app passwords do? I'm looking for a yes or no answer to this.

Mukesh Kumar Atlassian Team Jul 20, 2022

Normal account credentials were not stored in the Credential manager.

Why was a perfectly good technology taken away for an inferior replacement that does not at all work reliably? You yourselves are advising against the very thing you replaced normal passwords with. I understand that you don't have control over the underlying technology you built app passwords on, but if that underlying technology is unreliable, it by default makes the feature you built on top of it unreliable.

 

Why did you choose an unreliable and unstable technology stack to replace normal user account passwords with? I would like an answer to this.

Mukesh Kumar Atlassian Team Jul 27, 2022

That's the technology available for this purpose.

Atlassian account password for Bitbucket API and Git activity has been deprecated to improve Atlassian account security (more info). 

We would suggest trying to use the OAuth authentication method.

Hello @mai_il_2011,

Stephen Sifers here, Product Lead for Community. Firstly, I want to let you know personally I've reviewed and read through this thread and heard your concern about the change and the problems it is causing you and your team. I hear your frustration around not getting a direct nor acceptable answer and wanted to ensure we give you the best path forward. For your questions around a feature change within our products in regards to passwords.

We had multiple announcements around this change and ensured it was communicated well before the change occurred; please see the following.

Additionally, while it is unfortunate that you're having your sessions dropped while using an app password, there are multiple environmental variables that could be the cause of this. Mukesh and I are not wanting to blame others but simply stating a matter of fact when applications are installed on client-side devices that are governed outside the control of Atlassian-hosted applications. Other options have been provided to assist with your credential issues, such as OAuth. You may also use an SSH Key as another alternative.

If you're unable to implement any of the provided solutions, we ask you to review our New Features Policy to understand how new features and suggestions are processed (Implementation of New Features Policy).

You're also welcome to submit feedback outside of your existing support request at Feedback for the Founders.

I hope the information above provides insight into the changes along with alternatives you may use to find the cause of your credential issues. We have heard your feedback, and we are listening.

 

Regards,

Stephen Sifers, Community Product Lead

0 votes

Hello @mai_il_2011 ,

I firstly want to apologize for the run-around and back and forth you've been having to deal with regarding this issue. This is by no means the experience we want for customers. From reviewing your support case I do see the developers are working on reviewing your issue to find a root cause but there is presently no update. Your support case is the best place to receive updates on this issue.

If you're having further issues with this issue please let me know via this thread.

Regards,
Stephen Sifers

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events