Error when creating workspace if the user password contains non-cmd-friendly characters

(Edited by F.: please see the steps to reproduce and workaround below.)

I tried to use this plugin for the first time today and trying to create my local workspace failed with a crash. This is trying to connect to an organisation tfs server.

Repro Steps

1. Open any IntelliJ based IDS (I used Rider for this)
2. On the welcome screen, click on “Get from Version Control”
3. Select “Respository URL”
4. From the “Version control” drop down, choose “Azure DevOps TFVC”
5. Click “Clone”
6. In the “Checkout from Azure DevOps Services”, select the “Team Foundation Server” tab
7. • Enter your server URL
8. Select a Repository and keep other default settings
9. • Click “Create Workspace”

• During this process, I had to accept the server’s certificate.

What should happen

The workspace is mapped on my machine and files starts to download into the specified folder. If the “Edit workspace” checkbox is checked, I would expect to chose what files will get downloaded.

What happened instead

After a bit of loading, the window closes bringing me back to the welcome screen. The Event Log icon on the bottom right appears red. Clicking on it shows an “IDE Fatal Error” with the following stack trace:

java.lang.RuntimeException: An error occurred: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

	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)

[ForNeVeR]

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).

[ForNeVeR]

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.