Just as a counter point to all the jubilation, we are using the Umbrella SSO plugin with a GSS/Kerberos protected frontend, This means non of our users have to type in passwords or manage ssh keys, but they do have to use user@ in the url to get the authentication to work correctly. For us this is a breaking change and we will need to add the variable to the properties file to maintain the old behavior. This seems the opposite to how new functionality should be introduced. I'd have liked to see the new variable switch the new behavior on, not off. 

As for the change itself - thank you!  I plan to suggest in my "what you'll get with the upgrade" notes that users who would be affected and might not want to enter their username each time start using SSH keys ahead of the upgrade

Just leverage Git credentials utilities. SSH has nothing to do with this:

• for Windows:
  $ git config --global credential.helper wincred
  which stores the credentials inside the Windows Credentials Store (hit the Windows key and type "Credential Manager" to see what's in there)
  $ git config --global credential.helper “/mnt/c/[Program\ Files/Git/]mingw64/libexec/git-core/git-credential-wincred.exe”
  if you're using WSL
• for Mac:
  $ git config --global credential.helper osxkeychain
  which stores the credentials in the keychain
• for Linux:
  if you're using a Gnome based distro:
  $ git config --global credential.helper gnome-keyring
  which stores the credentials in the Gnome keyring
  or code your own credentials helper and feel the power of open source at the tip of your fingers (see https://www.kernel.org/pub/software/scm/git/docs/technical/api-credentials.html)

If you want to find out which credential helpers are available with your Git setup:
$ git help -a | grep credential-

In last resort, you go with:
$ git config --global credential.helper store
which stores the credentials unencrypted in ~/.git-credentials, see https://www.kernel.org/pub/software/scm/git/docs/git-credential-store.html)

See, username in URLs have never been needed with Git 🤷‍♂️

Kristy - Belated thanks for the pointer.  Yes, I saw it there after I had completed my upgrade analysis planning (but before I upgraded).  In the list it didn't jump out as something that would change end user behavior - I just read it because it looked interesting...

As to your question about "anything extra that I would have liked"...  First let me say I love your release notes format where you highlight new features and list all of the other changes.  It is incredibly useful and I appreciate the amount of time you must spend to get this "end user ready".  I also completely understand that you can't further emphasize every change that you document in the changelog, but I also know that it is hard for someone planning an upgrade to read every change and determine if it will negatively affect them.  My comment was only was that this particular change was more important to know about since it can change the end user experience.  Also, if it ended up causing enough angst that we needed to restore the previous behavior, we would need a restart.  We operate globally and have to count and (justify to senior leadership) every service interruption.  That would be two strikes against us in the end user experience of the upgrade   If it was listed in the summary of the release notes to bring attention to it as part of upgrading to this version, people could make up-front decisions, warn users of what they need to do, etc.

As for the change itself - thank you!  I plan to suggest in my "what you'll get with the upgrade" notes that users who would be affected and might not want to enter their username each time start using SSH keys ahead of the upgrade.  If anyone has run into situations beyond "I don't want to type my username at a prompt", I would be interested so I can maybe cut some of those issues off too.  Thanks!

I just happened upon this when doing some upgrade planning.  It might be helpful if was highlighted as changed behavior in your release notes.  Now that I know this, I will either include in our upgrade impact statements that end users with older versions of git need to either upgrade or manually add the username back into their URLs.  Thanks for your consideration.

@Bryan Turner

Nope, the bitbucket.properties http.cloneurl.includeusername=true will meet my needs.  No further action required on your part.

I just wanted to post a public comment here because I suspect that somebody, somewhere out there is going to upgrade to Bitbucket 5.12.0 and suddenly their RHEL/CentOS users on older git versions will not be able to clone using the provided HTTPS URL given by the web UI.

jeffrey.thornsen,

Is there something specific you'd like to see done for that? You can set http.cloneurl.includeusername=true in bitbucket.properties when you upgrade and Bitbucket Server will continue to include the username in the URL. (You'll also continue to have the auth "errors" from BSERV-9904, but that's the trade-off.)

Is there something else we can do to improve the scenario? When you're browsing the UI the application can't know what version(s) of Git you'll eventually clone with, so it's not possible to conditionally include or exclude the username based on that. Having whether to include the username or not configurable per-user represents a significant amount of work, and is likely to be a poor-to-mediocre "improvement" on the situation--users would still need to know that, for their Git version, they need to opt into including the username, and it would put any improvement on BSERV-9904 in the hands of users (unless we built a way for sysadmins to force the flag one way or another--in which case we're right back to your issue).

Thoughts?

Best regards,
Bryan Turner
Atlassian Bitbucket

I know this issue is somewhat old, but the fix is coming in a new version of Bitbucket Server and I would like to point out that a large number of my users are on Red Hat / CentOS 6 and 7, which ship with fairly old versions of git (1.7.x and 1.8.x).  These versions of git require that you specify the username in HTTPS clone URLs.  Without the username, these versions of git appear to just bomb out and never attempt to ask the user for credentials (well, I know at least my users on RHEL6/CentOS6 had this issue).

Most experienced git users will set up SSH keys anyway, but users who are completely new to git would get confused when the clone URL given to them by the tool (without a username in the HTTPS clone URL) didn't work on their CentOS 6 computer.

Bitbucket Server 5.12 will remove the username from HTTP(S) clone URLs by default. (Related: "git" is still present in SSH clone URLs, and we currently have no plans to remove or replace it.)

If having the username in HTTP(S) clone URLs is important, it can be restored instance wide by setting http.cloneurl.includeusername=true in bitbucket.properties. It is not possible to selectively enable/disable including the username.

Best regards,
Bryan Turner
Atlassian Bitbucket

As others have mentioned having the user name in the URL leads to a flood of unnecessary Auth errors in the case of HTTPS.

A bug has been logged for that issue as well. BSERV-9904

If my assumption is correct then I think there will be far more occurrences of users sharing URLs with others and having the username present which will cause more mistakes and problems than not having the username.

THIS

And people adding submodules with usernames in URLs (which you mentioned)... The pain never ends.

Thanks for the clarification.  I checked around and it does seem like the CAPTCHA issue has been resolved since we switched to 4.6.2.  This particular issue was one that would go away for a while and then return suddenly with no warning.  There were occasions we didn't see a CAPTCHA for a couple months and then we would get it several times in a week. 

In the original issue description I also indicated that embedding the username causes issues when people are creating submodules if they mistakenly copy/paste the URL into the submodule add command.  In other situations where users share repository URLs they need to remember to stirp the username.  In your original response you stated:"Further, while removing the username is needed in some cases, there are a good many where people don't and if we were to remove it, some may not even realise that including it the URL is possible and often desirable".  In a later response you stated: "Having the username included decreases data entry (and propensity for mistakes) for several use cases, the simplest being a git clone command".

So the second response answers at least one of the cases where it might be desirable.  Are there others?  I suspect most users use a credential manager of some type so that they don't have to enter username/password for each operation.  So data entry errors would be rare overall.  SourceTree for example stores this information so I don't need to authenticate each time.  If my assumption is correct then I think there will be far more occurrences of users sharing URLs with others and having the username present which will cause more mistakes and problems than not having the username.

I can imagine several solutions to this issue:

• Global setting that the system admin makes.  Username is enabled/disabled for all. 
• Project setting that the project creator can set.  Username is enabled/disabled/default for all repositories in the project.
• Repository setting that the repository creator can set.  Username is enabled/disabled/default for the repository.
• User setting that a user can set.  Username is enabled/disabled/default based on user preference.

Actually all the above options could possibly be implemented. The precedence would be in reverse order from what I listed.  User overrides all settings unless default is selected.  Default would use the default for the repo/project/global.  Repo and project would also allow a default.  At the global level the Bitbucket would default to enabled to retain backwards compatibility.  I can also imagine that at each level there could be a setting that specifies the higher level setting can not be overridden by a lower level setting.  That way a system admin could globally enable username and then indicate that project/repo and users cannot override that setting. This is probably going overboard but it does provide maximum configurability.

stevew1,

That's right. If there are no credentials provided, we no longer count it as a "miss" and it doesn't increment the counter toward the CAPTCHA limit. That means whether the username is in the clone URL or not, it won't ever lead to a CAPTCHA on its own now. We decided ignoring attempts without credentials wouldn't impact the overall security of the system because repeatedly passing the same empty password isn't going to help brute-force a user's actual password; it'll just confirm they have one. That should be a guarantee anyway because surely no administrator would allow users to have empty passwords in the first place.

The assumption that users can't have empty passwords is even more safe because, since Stash 2.8 (released September 30, 2013), the system doesn't even attempt to authenticate requests with empty passwords; it just rejects them. In the nearly three years since 2.8 was released we haven't had any reports of cases where users with empty passwords suddenly weren't able to authenticate, which suggests there weren't any users with empty passwords to be locked out.

Best regards,
Bryan Turner
Atlassian Bitbucket

We were using 3.11.2.  We've since upgraded to 4.6.2.  I don't know if we've seen the CAPTCHA issue since the upgrade but I'll check into it.  Just to be clear, you saying that if the username is passed to Bitbucket 4.6+ and a password is not provided then the CAPTCHA is bypassed. It's only when password is provided that CAPTCHA would trigger. 

stevew1

Re: "If several processes all attempt access at the same time you will have a failure for each attempt. This will cause the CAPTCHA trigger to fire if enabled.", what version of Stash or Bitbucket Server were you running when this happened? If the username is in the URL, the first request is sent with an empty password. Starting from 4.6 (and maybe earlier, but definitely 4.6+), CAPTCHA is bypassed if credentials are not provided. That means with newer versions of Bitbucket Server that point is no longer true.

I'm not weighing in on the feature request itself; just pointing out that that particular reason isn't valid in the current version.

Best regards,
Bryan Turner
Atlassian Bitbucket

Even when cloning with SSH URLs, the username is useless and is asking for trouble.

I would also love to be enlightened about the use cases where having the username in the URL is the way to go.

IMHO, credentials should be handled by Git and its credentials helpers.

I hope an option gets implemented soon.

Some additional thoughts on this request.
1. Including the username in the URL causes additional authentication error messages for a valid user in the logs since the first attempt will always result in a failed access attempt since the password is missing. This can make it more difficult to determine if someone is trying to hack into the account since there will always be an unauthorized access.
2. When using multiple CI systems or a single CI system with a multiple configurations running in parallel, each attempt to access the repository will result in an authentication error. If several processes all attempt access at the same time you will have a failure for each attempt. This will cause the CAPTCHA trigger to fire if enabled. We've had this problem with one of our CI systems. Access Keys would probably work around this issue but we currently aren't set up to use those.
3. Including the user@ in the URL of a submodule is bad. Since a user is likely to copy and paste the URL when adding a submodule they may accidently forget to remove the user@ mention from the URL. This will result in an authentication error when others attempt to access that submodule. In addition, it will cause the CAPTCHA trigger to fire for the user that has their username in the URL.

What I would like to see is a way to suppress the user@ from the URL. Having the username default to be included is fine but provide a configuration option to suppress it. This could be a global to Bitbucket Server, per project, per repo or per user configuration (or any combination of those). For users that are using wincred, SourceTree or other methods of supplying credentials having this feature turned off results in fewer issues overall.

I'm reopening this so people can weigh in. Having the username included decreases data entry (and propensity for mistakes) for several use cases, the simplest being a git clone command. On the other hand, this can cause confusion when people keep the username and break the portability for submodules or separate credential management tools. We may reconsider the current approach as a result.

I'm also curious about those cases. I would also vote for it if it wasn't closed already.

Another reason to either remove this (or at LEAST make it an option) is that for command line clients, using the username@ in the clone URL triggers a AuthenticationFailureEvent for every git operation, since it first fails, and then prompts for a password. For our instance, we have no need for the username@ in the clone URL. It would be really awesome if we had the option.

Can such a thing be accomplished with a plugin? If not, do you think we could reopen this (or make a new feature request) to expose this setting through the Java API?

p.s. I have posted two questions related to this issue
https://answers.atlassian.com/questions/10412373/authentication-failures-in-atlassian-stash-audit.log-for-every-git-operation-but-users-not-seeing-any-failures
https://answers.atlassian.com/questions/10417956/how-can-i-change-the-default-clone-url-provided-by-stash

The response by Roger Barnes indicates that there are cases where having the user name is desirable. I asked under conditions this is true and never received a response. I'm still curious what those cases are.

I would like to vote for this to be implemented configurable on repository setting base.
In our Company we as central IT for about 1000 employees provide GIT Repositories on a Service base. Thus - although we started providing this services - we already hat a lot of service requests regarding that sharing the Repository URL to others is a mess, as you always have to remove the username...

Like Steven I'm curious when the username is advantageous. It's a problem in at least these cases:

• Using it as a submodule url
• When "taking over" somebody's source tree, it has the username littered everywhere so you can't just change your authentication context (ie. Pageant or .netrc) and have the repos work properly.

Basically, authentication should be orthogonal to repository location, but you've merged the two and that causes complications. I'll have to train my team to remove the username as regular practice.

Thank you for the feedback. I'm curious under what situations is having the username in the URL desirable.

Hi Steven,

I've discussed your suggestion with a few colleagues. On the surface it is a pretty reasonable request. We feel that having a global option would be giving a somewhat arbitrary choice to only one user of an instance and would be hesitant to add such an option at a lower level. Further, while removing the username is needed in some cases, there are a good many where people don't and if we were to remove it, some may not even realise that including it the URL is possible and often desirable. So, unfortunately, I'm afraid we're not likely to change this for the time being. Sorry I can't provide a more positive answer for this one.