azure-devops-intellij: Error when creating workspace if the user password contains non-cmd-friendly characters

Alright, I was able to reproduce the issue.

Prerequisites:

1. Use on-premise Azure DevOps server (dev.azure.com won’t work because it uses other authentication token format; “alternate password” mechanism could work but it is getting obsoleted anyway).
2. Azure DevOps Server user should have unusual character in their password (e.g. ^).

Steps to reproduce:

1. Check out a repository from the IDE welcome screen: authenticate on server using your login/password
2. The authentication will work (!), the repository list will be loaded. Select a repository and path to check it out, press Checkout

The error will be shown:

java.lang.RuntimeException: An error occurred: Access denied connecting to TFS server http://desktop-i35dvo5/ (authenticating as friedrich)

	at com.microsoft.alm.plugin.external.commands.Command.throwIfError(Command.java:423)
	at com.microsoft.alm.plugin.external.commands.CreateWorkspaceCommand.throwIfError(CreateWorkspaceCommand.java:91)
	at com.microsoft.alm.plugin.external.commands.CreateWorkspaceCommand.parseOutput(CreateWorkspaceCommand.java:73)
	at com.microsoft.alm.plugin.external.commands.CreateWorkspaceCommand.parseOutput(CreateWorkspaceCommand.java:22)
	at com.microsoft.alm.plugin.external.commands.Command$1.completed(Command.java:178)
	at com.microsoft.alm.plugin.external.ToolRunner$ListenerProxy.completed(ToolRunner.java:295)
	at com.microsoft.alm.plugin.external.ToolRunner$ProcessWaiter.run(ToolRunner.java:333)

Investigation: the problem is that under some circumstances we pass the login/password pair through cmd on Windows, and cmd is known for its really crazy rules of argument passing. Namely, ^ character is escape character in some contexts.

Workaround: the workaround here would be to switch the command-line client code to the so-called “fast-mode” (which isn’t so fast, but still). I’ll copy the information from my previous take on the issue, https://github.com/microsoft/azure-devops-intellij/issues/252#issuecomment-544838137:

So, we have two ways of running the TF client: the “fast one” and the “slow one”.

In the slow mode, we’re passing all the arguments through the client command line (and it breaks for some reason on your machine: probably the credentials themselves are too long which happen sometimes).

In the fast mode, we start the client “worker” process with the only argument @ which means “read the command line from stdin”, and then pass the arguments through stdin, which is probably more reliable.

For now, your workaround would be to do one of this:

1. open your TFVC settings and press the Test button on the client setup page: it should load the client version and will allow it to use the “fast mode” that isn’t so bugged
2. always check out the repositories from the already started IDE (e.g. open another TFVC project before checking out a new one): when opening any TFVC project, we cache the client version, too, and will use the “fast mode” for further actions, even for checking out a new project

I have verified that this workaround works in my case (with unusual character in password).

Thanks for help. Do you use on-premise installation of TFS/Azure DevOps server with HTTPS support? In that case, you’ll have to install your server’s certificate into our JVM (we’re working on a fix for that, but for now it’s a requirement).

Take a look at this article, “Importing the certificate” section.