How to escape special characters in connection string passed to CrmServiceClient constructor

1.7k views Asked by At

The CrmServiceClient class in the Microsoft.Xrm.Tooling.Connector namespace has a constructor that takes a connection string as a single argument (documented here: https://learn.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/xrm-tooling/use-connection-strings-xrm-tooling-connect?view=op-9-1).

This connection string is similar/familiar to other uses of connection strings (with name/value pairs separated by equal signs and delimited with semi-colons), but I cannot find any firm documentation to suggest the specific rules for escaping special characters. If in this particular context a connection string value must include an equal sign or semicolon, how is that escaped? While there is some documentation about SQL and Entity Framework connection strings, those are used in completely different contexts, so I don't see any reason to believe that documentation in those contexts applies to the CrmServiceClient constructor context.

Does anyone have a pointer to definitive documentation for this context, and/or sufficient experience in this context to venture a fairly definitive ad hoc description?

Thanks.

===========================ADDED IN RESPONSE TO REQUEST IN COMMENT

In the comments to the initial question above, a kind contributor requested that I add more detail about my user story. The request was that I add my own builder/parser.

I will not be creating a parser. The parser will be the one used by the CrmServiceClient constructor. It is part of the Xrm Tooling Connector.

I have not yet created a builder to build the connection string that will be passed to the CrmServiceClient constructor. And my first task will be to create a unit test for that builder that will determine whether it was built correctly or not, which is why I would like the definitive rules enforced by the parser.

Take the following example connection string:

AuthType=OAuth;[email protected]; Password=passcode;Url=https://contosotest.crm.dynamics.com;AppId=51f81489-12ee-4a9e-aaae-a2591f45987d; RedirectUri=app://58145B91-0C36-4500-8554-080854F2AC97;LoginPrompt=Auto

In this basic example, there is no value anywhere in the set of key/value pairs of the connection string that has any special characters in it, so nothing needs escaping. But now let us imagine that the Password is not the string "passcode", but instead is full of special characters. Let us say that the password is

"aB4$;";~^''dEfg'!

That password itself starts with a double quotation mark, has another double quotation mark in it, has two single quotation marks and two semicolons. It is not unreasonable to expect that a password might have characters like this. If the connection string passed to the CrmServiceClient constructor is exactly this:

AuthType=OAuth;[email protected]; Password="aB4$;";~^''dEfg'!;Url=https://contosotest.crm.dynamics.com;AppId=51f81489-12ee-4a9e-aaae-a2591f45987d; RedirectUri=app://58145B91-0C36-4500-8554-080854F2AC97;LoginPrompt=Auto

Then for sure it will be parsed incorrectly.

This is the problem I am trying to solve with a set of definitive rules used by the CrmServiceClient constructor parser.

1

There are 1 answers

2
Stephan G On

Inferred, but not documented and guaranteed answer:

I decompiled the XRM Toolkit code, and the constructor in question. It does appear that very far under the hood, the same parser is being used that Microsoft uses for connection strings for databases and the like, in System.Data.

In addition, there is a public (but undocumented) extension method that will take a CrmServiceClient connection string as an argument and return a Dictionary<string,string> of the the key/value pairs parsed out of the connection string. That method is: Microsoft.Xrm.Tooling.Connector.Extension.ToDictionary().

From using that method, I can determine that the following works as ONE set of defacto rules that can be used for building connection strings:

  1. Connection string values MAY always be enclosed in single quotes.
  2. If the connection string value is to have any special characters in it, it MUST be surrounded by single quotes. (NB - double quotes are also acceptable, but I am using single quotes for my purposes.)
  3. Special characters definitely include leading and trailing whitespace, semicolon, and single quotes. This list may not be exhaustive.
  4. If you need to include a single quote inside a connection string value, you must double it to escape it.