Добавление сторонней проверки подлинности в универсальные действия адаптивных карточек

Универсальные действия адаптивных карточек используют бота в качестве общей серверной части для обработки действий и представляют новый тип Action.Executeдействия , который работает в разных приложениях, таких как Teams и Outlook.

Примечание.

Поддержка схемы универсальных действий адаптивных карточек версии 1.4 доступна только для карточек, отправленных ботом.

Вы можете включить следующие сценарии с универсальным Action.Execute действием адаптивных карточек:

• Универсальные действия
• Пользовательские просмотры
• Последовательные рабочие процессы
• Представление "До даты"

Дополнительные сведения об универсальных действиях адаптивных карточек см. в статье Универсальные действия адаптивных карточек.

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

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

Поток проверки подлинности в протоколе Action.Execute

Поток проверки подлинности для OAuth в рамках Action.Execute протокола включает проверку подлинности в контексте группового чата или беседы канала, в которой предоставляется общий доступ к адаптивной карточке.

Боты могут отвечать запросом на вход в ответ на следующие действия Action.Execute :

• Адаптивные карточки, отправленные ботом в одном чате, групповом чате или канале.
• Адаптивные карточки, отправленные пользователем приложения через приложение расширения сообщений (при поддержке бота) в одном чате, групповом чате или канале.
• Адаптивные карточки, представленные в области создания или предварительного просмотра, пока пользователь создает сообщение. В области создания выполняется обновление в адаптивной карточке, и боту может потребоваться использовать маркер для предоставления пользовательского представления пользователю приложения перед отправкой карта в чат.

Начало работы с OAuth или номинальным потоком входа

Шаги OAuth или номинальной проверки подлинности для адаптивных карточек с универсальными действиями похожи на бота в Teams.

Убедитесь, что вы добавили проверку подлинности в бот Teams. Дополнительные сведения о создании бота с поддержкой проверки подлинности, развертывании бота в Azure и его связывании с поставщиком удостоверений, а также об интеграции бота в Microsoft Teams см. в статье Добавление проверки подлинности в бот Teams.

Для OAuth или номинального входа, в котором пользователю предоставляется кнопка входа или ссылка, ниже приведен поток входа OAuth или номинальный вход:

1. Клиент Teams отправляет боту адаптивную карточку или actionInvokeActivity запрос.

2. Бот использует протокол службы маркеров для проверка, если для пользователя, указанного в activity.from.id поле, уже есть кэшированный маркер. Канал указан в activity.channelId поле для бота и настроенного подключения.

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

   {
     'statusCode': 401,
     'type': 'application/vnd.microsoft.activity.loginRequest',
     'value': {
        'text': 'Please sign-in',
        'connectionName': '<configured-connection-name>',
        'buttons': [
           {
              'title': 'Sign-In',
              'text': 'Sign-In',
              'type': 'signin',
              'value': '<sign-in-URL>'
           }
        ]
     }
   }   
   

   • Отправители должны включать значение, которое соответствует формату OAuthCard.
   • Отправители должны содержать .connectionName Получатели могут игнорировать запросы на вход с пустым или отсутствующим connectionName.
   • Отправители должны содержать объект , button имеющий массив непустых кнопок.

4. После получения этого ответа клиент Teams отображает кнопку Вход в нижнем колонтитуле карта, где пользователь может войти.

   

5. Когда пользователь нажимает кнопку Вход , в окне браузера откроется страница входа поставщика удостоверений. После входа пользователя появится страница Служба маркеров со значением кода авторизации.

6. Клиент Teams создает и отправляет adaptiveCard/action действие вызова с помощью name. Значение включает поле, state содержащее код авторизации:

   {
      'type': 'invoke',
      'name': 'adaptiveCard/action'
      'value': {
         'action': {
            'id': 'abc123',
            'type': 'Action.Execute',
            'verb': 'saveCommand',
            'data': {
               'firstName': 'Jeff',
               'lastName': 'Derstadt'
            }
         },
      'state': '123456'
      },
      ...
   }
   
   

   Отправители должны содержать state поле.

7. Канал доставляет этот вызов боту, который использует код проверки подлинности для получения маркера из службы маркеров. Служба маркеров доставляет боту маркер доступа пользователя.

   Получатели могут игнорировать adaptiveCard/action вызов или отвечать с ошибкой, если поле отсутствует или пусто state .

   Если значение в state поле неверно, бот возвращает клиенту Teams ошибку следующим образом:

     {
      'statusCode': 401,
      'type': 'application/vnd.microsoft.error.invalidAuthCode',
     }
   

   Клиент Teams может снова запросить у пользователя правильный код авторизации или отправить Action.Execute запрос еще раз.

8. Если код авторизации в state поле правильный, бот использует маркер доступа от имени пользователя для выполнения своих действий.

9. Бот отвечает карта или сообщением клиенту Teams без ошибок.

См. также

• Работа с универсальными действиями адаптивных карточек
• Включение единого входа для универсальных действий адаптивных карточек