tfx-cli login incorrectly parses on-prem address

[roryprimrose]

We have installed a TFS instance on-prem without the tfs sub-web. We then want to upload custom build steps using node tfx-cli login --service-url http://tfs.corp.local/DefaultCollection/

This fails after putting the PAT in with the error

Invalid service url - path is too long. A service URL should include the account/application URL and the collection, e.g. https://fabrikam.visualstudio.com/DefaultCollection or http://tfs-server:8080/tfs/DefaultCollection

http://tfs.corp.local/DefaultCollection/ is the correct location of our collection

Any way around this?

[jpenniman]

I'm having the same issue. Any luck?

[jpenniman]

I found our problem. The application is hard coded in the tfx-cli as "tfs", expecting the url to always look like.. http:/server:port/tfs/collectionName

The problem is, the admins made the application the company name, so our url actually looks like: http://server:port/ContosoTFS/CollectionName

So it fails the parse. As a result, we cannot upload custom build tasks to our on-prem TFS 2018 server.

The offending code: https://github.com/Microsoft/tfs-cli/blob/master/app/lib/connection.ts

if (splitPath.length === 2 && splitPath[0] === "tfs") {
    // on prem
    this.accountUrl += "/" + "tfs";
} else if (!this.parsedUrl.protocol || !this.parsedUrl.host) {
    throw new Error("Invalid service url - protocol and host are required");
} else if (splitPath.length > 1) {
    throw new Error(
        "Invalid service url - path is too long. A service URL should include the account/application URL and the collection, e.g. https://fabrikam.visualstudio.com/DefaultCollection or http://tfs-server:8080/tfs/DefaultCollection",
    );
} else if (splitPath.length === 0) {
    throw new Error("Expected URL path.");
}

[binpick]

Is there any update on this? Does anyone has a workaround to publish an extension to on-prem server?

[Tetha]

A colleague of mine just hit this issue. In doubt, you can use mitmproxy in reverse mode as an adhoc URL rewriter. This shouldn't be too horrible from a security point of view, as the connection from the system running mitmproxy to the target TFS server should still be authenticated and encrypted and plaintext communication between tfx-cli and mitmproxy only happens on localhost.

Assume that $TFS_URL is the url of your server, for example "azdops.internal.example.com" and $ONPREM_PREFIX is your local URL path part.

Then you can start mitmproxy:

 mitmproxy --mode "reverse:https://$TFS_URL" --map-remote "|https://$TFS_URL/tfs|https://$TFS_URL/$ONPREM_PREFIX"  

This sets up mitmproxy as a reverse proxy for your local azdops/tfs server and sets up a URL rewrite in mitmproxy to replace the /tfs with your $ONPREM_PREFIX.

Afterwards, you throw your tfx-cli against localhost:8080

tfx-cli extension publish --service-url http://localhost:8080/tfs --vsix ....

This allowed my colleague to work with tfx-cli against an onprem address with a suffix other than /tfs. It doesn't feel the best, but it works.