Как избежать специальных символов в строке подключения, переданной в конструктор CrmServiceClient

Класс в пространство имен имеет конструктор, который принимает строку подключения в качестве единственного аргумента (задокументировано здесь: https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/xrm-tooling/use-connection-strings-xrm-tooling-connect?view = op-9-1).

Эта строка подключения похожа / знакома с другими видами использования строк подключения (с парами имя / значение, разделенными знаками равенства и разделенными точками с запятой), но я не могу найти какой-либо твердой документации, предлагающей конкретные правила для экранирования специальных символов. Если в данном конкретном контексте значение строки подключения должно включать знак равенства или точку с запятой, как это экранировать? Хотя существует некоторая документация о строках подключения SQL и Entity Framework, они используются в совершенно разных контекстах, поэтому я не вижу причин полагать, что документация в этих контекстах применяется к контексту конструктора.

Есть ли у кого-нибудь указатель на исчерпывающую документацию для этого контекста и / или достаточный опыт в этом контексте, чтобы отважиться на довольно окончательное специальное описание?

Спасибо.

=========================== ДОБАВЛЕНО В ОТВЕТ НА ЗАПРОС В КОММЕНТАРИИ

В комментариях к начальному вопросу выше, любезный участник попросил меня добавить более подробную информацию о моей пользовательской истории. Просьба заключалась в том, чтобы я добавил свой собственный конструктор / парсер.

Я не буду создавать парсер. Парсер будет использоваться конструктором. Это часть соединителя инструментов Xrm.

Я еще не создал конструктор для построения строки подключения, которая будет передана конструктору. И моей первой задачей будет создание модульного теста для этого построителя, который определит, был ли он построен правильно или нет, поэтому я хотел бы, чтобы синтаксический анализатор соблюдал определенные правила.

Возьмите следующий пример строки подключения:

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

В этом базовом примере нигде в наборе пар ключ / значение строки подключения нет значения, содержащего какие-либо специальные символы, поэтому экранирование не требуется. Но теперь давайте представим, что Пароль не является строкой «пароль», а вместо этого содержит специальные символы. Допустим, пароль

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

Сам этот пароль начинается с двойных кавычек, в нем есть еще одна двойная кавычка, есть две одинарные кавычки и две точки с запятой. Вполне разумно ожидать, что пароль может содержать подобные символы. Если строка подключения, переданная конструктору, будет именно такой:

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

Тогда уж точно будет некорректно разбираться.

Это проблема, которую я пытаюсь решить с помощью набора окончательных правил, используемых парсер конструктора.

1 ответ

Предполагаемый, но недокументированный и гарантированный ответ:

Я декомпилировал код XRM Toolkit и рассматриваемый конструктор. Похоже, что очень далеко под капотом используется тот же парсер, который Microsoft использует для строк подключения для баз данных и тому подобного, в .

Кроме того, существует общедоступный (но недокументированный) метод расширения, который принимает строка подключения в качестве аргумента и вернуть пар ключ / значение, извлеченных из строки подключения. Этот метод: .

Используя этот метод, я могу определить, что следующее работает как ОДИН набор правил defacto, которые можно использовать для построения строк подключения:

  1. Значения строки подключения МОГУТ всегда заключаться в одинарные кавычки.
  2. Если значение строки подключения должно содержать какие-либо специальные символы, оно ДОЛЖНО быть заключено в одинарные кавычки. (NB - двойные кавычки также допустимы, но я использую одинарные кавычки для своих целей.)
  3. Специальные символы обязательно включают начальные и конечные пробелы, точку с запятой и одинарные кавычки. Этот список не может быть исчерпывающим.
  4. Если вам нужно включить одинарную кавычку в значение строки подключения, вы должны удвоить ее, чтобы избежать ее.
Другие вопросы по тегам