Loading
Настройка и обслуживание организации Salesforce
Содержание
Фильтровать по (0)Добавить
Выбрать фильтры

          Результаты отсутствуют
          Результаты отсутствуют
          Ниже приведены некоторые советы по поиску.

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

            Выполните поиск по всей справке Salesforce.
            Выполните поиск по всей справке Salesforce.
            Использование ключей API в настраиваемых заголовках с именованными регистрационными данными

            Вы находитесь здесь:

            1. Справка Salesforce
            2. Документы
            3. Настройка и обслуживание организации Salesforce

            Использование ключей API в настраиваемых заголовках с именованными регистрационными данными

            Веб-службы часто определяют собственные протоколы проверки подлинности посредством настраиваемых заголовков. В этих случаях можно создать настраиваемый заголовок для именованных или внешних регистрационных данных и использовать ключи API в качестве пароля.

            Требуемые версии

            Доступно в версиях: Salesforce Classic (недоступно во всех организациях) и Lightning Experience.
            Доступно в версиях: все версии

            Схема именованных регистрационных данных содержит поддержку протоколов проверки подлинности, например, OAuth 2.0 и AWS Signature v4. Некоторые поставщики веб-служб имеют собственные протоколы проверки подлинности, использующие уникальные заголовки для проверки подлинности. В этих случаях выберите протокол проверки подлинности Custom для внешних регистрационных данных и используйте настраиваемый заголовок для проверки подлинности в таких системах.

            Одним из распространенных методов, используемых поставщиками веб-служб для настраиваемой проверки подлинности, являются ключи API. Кроме проверки подлинности, ключи API также могут использоваться для разных служб, связанных с HTTP, например, кэширования или cookie-файлов. Для именованных регистрационных данных можно создать настраиваемый заголовок, использующий ключи API в качестве протокола проверки подлинности, секретное значение ключа которого функционирует в качестве пароля.

            Каждая веб-служба может произвольно назвать свои заголовки. Распространенные имена: ACCESS_TOKEN, bearer, Client-ID, developer-token и X-API-Key.

            В стандарте HTTP 1. x вызов с помощью жесткого API-ключа может выглядеть следующим образом.

            GET https://example.com HTTP/1.1
Client-ID: abc123

            Здесь Client-ID ключа API также является именем заголовка, а abc123 - значением ключа API, используемого для проверки подлинности. Имя и значение задаются системой проверки подлинности. Обычно эти параметры извлекаются посредством пользовательского интерфейса внешней системы.

            Стандарт HTTP содержит заголовок Authorization для проверки подлинности. По умолчанию, именованные регистрационные данные Salesforce используют этот стандартный заголовок авторизации. Однако, вы можете переопределить стандартный параметр и создать настраиваемый заголовок авторизации. Данный пример отображает заголовок Authorization, используемый с ключом API. 

            GET https://example.com HTTP/1.1 
Authorization: Client-ID abc123

            Ниже перечислены общие шаги по использованию ключей API с именованными регистрационными данными.

            1. Создайте внешние регистрационные данные, установив протокол проверки подлинности на «Настраиваемый». Внешние регистрационные данные хранят сведения о проверке подлинности и авторизации и используются именованными регистрационными данными.
            2. Сохраните ключ API в качестве параметра авторизации в субъекте.
            3. Создайте настраиваемый заголовок для внешних регистрационных данных. Заголовок ссылается на ключ API.
            4. Создайте именованные регистрационные данные, ссылающиеся на внешние регистрационные данные.

            Сохранение ключа API в качестве параметра проверки подлинности в субъекте

            Мы настоятельно рекомендуем сохранять параметры проверки подлинности ключа API как часть субъекта внешних регистрационных данных.

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

            Основной связывает внешние регистрационные данные с наборами полномочий и профилями. Добавление параметров проверки подлинности к субъекту позволяет разным группам пользователей Salesforce использовать разные маркеры проверки подлинности для вызова одной внешней службы.

            1. Создайте внешние регистрационные данные и задайте полю «Протокол проверки подлинности» значение «Настраиваемый». Инструкции по созданию и настройке внешних регистрационных данных см. в разделе «Создание или редактирование настраиваемых внешних регистрационных данных проверки подлинности». В данном примере внешние регистрационные данные называются MyCustAuthExternCred.

              Новые внешние регистрационные данные с настраиваемой проверкой подлинности

            2. На странице внешних регистрационных данных прокрутите страницу до основных показателей.
            3. Чтобы создать субъект, нажмите «Создать» и задайте данные поля.

              Соотнесение основным для настраиваемой проверки подлинности

              Имя параметра
              Имя субъекта (например, «Администратор» или «Группа маркетинга»).
              Порядковый номер
              Это число определяет, какое соотнесение используется для выноски, отсортированной от нижнего к верхнему. Задайте порядковый номер, если у пользователя есть несколько наборов полномочий, используемых в нескольких субъектах.
              Тип удостоверения
              Настраиваемая проверка подлинности использует тип удостоверения «Названный субъект». Названный субъект указывает, что пользователи Salesforce используют один ключ API и у них нет уникального доступа к внешней службе. Тип удостоверения для настраиваемой проверки подлинности изменить невозможно.
              Примечание
              Примечание В данный момент только протокол OAuth поддерживает уникальный доступ каждого пользователя к удаленной системе. В этом случае каждый пользователь входит отдельно, прежде чем интеграция работает в контексте пользователя.
              Имя
              Имя параметра проверки подлинности. В данном примере имя MyClientId.
              Значение
              Значение ключа API. Во многих случаях ключ API извлекается из пользовательского интерфейса веб-службы.
            4. Соотнесите субъект с набором полномочий или профилем. См. Включение включения внешних регистрационных данных. Вы можете соотнести субъект с несколькими наборами полномочий, группами наборов полномочий или профилями.

            Использование ключей API в настраиваемом заголовке

            После добавления ключей API к субъекту эти ключи можно использовать в настраиваемом заголовке.

            1. Во внешних регистрационных данных, созданных пользователем, прокрутите страницу до настраиваемых заголовков и нажмите «Создать».
            2. Заполните поля настраиваемого заголовка.

              Создание настраиваемого заголовка с помощью формул

              Имя
              Имя стандартного заголовка запроса HTTP, требуемого внешней службой. В данном случае выполняется проверка подлинности, поэтому используется стандартное имя HTTP «Авторизация».
              Значение
              Имя и значение ключа API. Это может быть литеральное или программное выражение.
              Значение может быть выражено программным способом посредством полей слияния и формул. Например, значение может принимать следующий вид.
              {!'Client-ID ' & $Credential.Container.ParameterName}
              В данном примере литеральная строковая Client-ID конкатенируется с ключом API, и выражение разрешает:
              {!'Client-ID ' & $Credential.MyCustAuthExternCred.MyClientId}
              Формулы могут использоваться в значениях заголовка посредством синтаксиса {!FormulaGoesHere}. Все внутри {!} оценивается как формула Salesforce. Формулы предоставляют значительные возможности и гибкость для создания значений заголовка без кодирования.
              Поля слияния предоставляют доступ к зашифрованным значениям посредством синтаксиса $Credential.Container.ParameterName. В данном примере контейнер является MyCustAuthExternCred внешних регистрационных данных. ParameterName - это основной MyClientId параметра проверки подлинности, соотнесенный со значением ключа API.
              Порядковый номер
              Это число определяет, какой заголовок «выигрывает» и используется для выноски, отсортированной от нижнего к верхнему. Если вас не беспокоят столкновения с другими заголовками, оставьте это поле по умолчанию.
              Теперь внешние регистрационные данные отображают настраиваемый заголовок с ссылкой на параметр авторизации, содержащий ключ API.

              Внешние регистрационные данные с настраиваемой проверкой подлинности

            Если Client-ID будет abc123, итоговая выноска будет выглядеть следующим образом. Именованные регистрационные данные дополняют поле «Авторизация»: в качестве имени заголовка. 

            GET https://example.com HTTP/1.1 
Authorization: Client-ID abc123
            Совет
            Совет Обязательно включите внешние регистрационные данные пользователя для пользователей, использующих именованные регистрационные данные. См. Включение внешних регистрационных данных пользователя.

            Использование ключей API с именованными регистрационными данными

            После создания внешних регистрационных данных, использующих ключи API, на них могут ссылаться именованные регистрационные данные.

            1. Выключите параметр «Создать заголовок авторизации» в именованных регистрационных данных. Отключение данного параметра обеспечивает использование созданного настраиваемого заголовка Authorization именованными регистрационными данными.
            2. В именованных регистрационных данных убедитесь, что параметр «Разрешить формулы в заголовке HTTP» включен.

            A callout using this named credential returns successfully because it has the correct Authorization header. If the tokens expire or the URL changes, no changes to Apex code are needed. In addition to Apex, the credential can be used in no-code tools such as External Services that provide integration with Flow.

            См. также:

             
            Загрузка
            Salesforce Help | Article