Botframework-solutions: La autenticación no funciona en la habilidad de TypeScript

Creado en 20 jul. 2020  ·  38Comentarios  ·  Fuente: microsoft/botframework-solutions

¿Qué proyecto se ve afectado?

Asistente virtual y habilidad de TypeScript

¿En qué idioma es esto?

Mecanografiado

¿Lo que sucede?

Se produce el siguiente error al intentar la autenticación

Error: DialogContext.beginDialog (): no se encontró un cuadro de diálogo con un ID de 'AuthPrompt'.
en WaterfallStepContext.(D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 123: 23)
en Generator.next ()
en D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 7: 71
en nueva promesa)
en __awaiter (D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 3: 12)
en WaterfallStepContext.beginDialog (D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 119: 16)
en MultiProviderAuthDialog.firstStep (D: \ home \ site \ wwwroot \ node_modules \ bot-solutions \ lib \ authentication \ multiProviderAuthDialog.js: 75: 34)
en WaterfallDialog.(D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ waterfallDialog.js: 192: 48)
en Generator.next ()
en D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ waterfallDialog.js: 7: 71

¿Cuáles son los pasos para reproducir este problema?

Implementar asistente virtual y habilidad. Habilite MultiProviderAuthDialog en la habilidad
Use el cuadro de diálogo de autenticación para autenticarse con Azure Active Directory v2

¿Qué esperabas que sucediera?

Reciba la tarjeta de inicio de sesión para iniciar sesión

¿Puede compartir algún registro, salida de error, etc.?

Error: DialogContext.beginDialog (): no se encontró un cuadro de diálogo con un ID de 'AuthPrompt'.
en WaterfallStepContext.(D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 123: 23)
en Generator.next ()
en D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 7: 71
en nueva promesa)
en __awaiter (D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 3: 12)
en WaterfallStepContext.beginDialog (D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ dialogContext.js: 119: 16)
en MultiProviderAuthDialog.firstStep (D: \ home \ site \ wwwroot \ node_modules \ bot-solutions \ lib \ authentication \ multiProviderAuthDialog.js: 75: 34)
en WaterfallDialog.(D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ waterfallDialog.js: 192: 48)
en Generator.next ()
en D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ waterfallDialog.js: 7: 71

¿Alguna captura de pantalla o contexto adicional?

Skills Bot Services Kobuk bug customer-replied-to customer-reported in-progress

Comentario más útil

¡Gracias de nuevo @ Batta32! Usé el paquete

Todos 38 comentarios

¡Gracias @ tomSauret847 por informar de este problema! Tan pronto como tengamos alguna actualización, te responderemos 😊.

Hola @ tomSauret847 , perdón por el retraso. Hemos reproducido con éxito el problema utilizando la habilidad TypeScript siguiendo estos pasos:

  1. Descomente las líneas en skillDialogBase marcadas para autenticación
  2. Pasar un OAuthPromptSettings matriz para el MultiProviderAuthDialog constructor
  3. Agregue appsettings.oauthConnections a las propiedades de botSettings
  4. Agregar una conexión AADv2
  5. Configurar una conexión AADv2 para el registro en Azure

Tan pronto como tengamos alguna actualización, te responderemos 😊.

image

Hola @ tomSauret847 : hemos solucionado este problema en esta confirmación .

En realidad, esto era un problema en la biblioteca bot-solutions , y hemos programado que la solución se publique con la versión 1.0 de la biblioteca.

Mientras tanto, si desea una forma de probar la solución por sí mismo, puede seguir estos pasos :

  1. Consulte esta rama , con la corrección aplicada para la versión 0.8 de la biblioteca.
  2. Vaya a la carpeta bot-solutions
  3. Ejecute npm install para instalar sus dependencias.
  4. Ejecute npm run build para construir la solución.
  5. Ejecute npm pack para generar un archivo .tgz . Debería crear un archivo en la misma ubicación, llamado bot-solutions-version.tgz
  6. Apunte al tgz generado en su Skill bot, reemplazando la referencia de bot-solutions en el paquete del bot.json de "bot-solutions": "^1.0.0" a "bot-solutions": "<PATH_TO_TGZ>"
  7. Validar la autenticación usando la habilidad

image

Estaremos atentos a tus respuestas 😊.

Gracias por investigar esto @ Batta32 Todavía recibo un error en este proceso. El error es
Error: no se pudo encontrar la configuración de conexión con el nombre {nombre de la conexión}

Estoy configurando la conexión como se describe aquí para configurar el SSO para una habilidad.

¿Todavía necesitamos tener una conexión de autenticación en cada habilidad con las habilidades de mecanografiado?
¿O podemos usar el SSO único como se describe para las habilidades de C #?

Si agrego la conexión en la habilidad, obtendré el mensaje de inicio de sesión como lo hizo usted, pero no recibiré el token después de completar el inicio de sesión. Si pudiera aclarar si necesitamos configurar una conexión única en VA o si necesitamos configurar conexiones en cada una de las habilidades que requieren autenticación.

Gracias @ tomSauret847 por su respuesta. Tan pronto como tengamos alguna actualización, te responderemos 😊!

Hola @ tomSauret847 : hemos reproducido correctamente el problema. Esto se debe a que la propiedad name en oauthConnections de appsettings.json difiere de la propiedad connectionName en el OAuthPromptSettings que está utilizando.

Continuaremos revisando esto y analizando las preguntas que ha mencionado anteriormente. Tan pronto como tengamos alguna actualización, te responderemos 😊.

Los pasos que seguimos para reproducir el problema fueron:

  1. Siga los pasos de este comentario.
  2. Después de esto, siga los pasos de este comentario.
  3. Compruebe que la propiedad name en oauthConnections de appsettings.json difiera de la propiedad connectionName en el OAuthPromptSettings que está utilizando
  4. Inicie la habilidad y escriba "ejecutar diálogo de muestra", y vea el error

_Cuando el nombre de conexión y el nombre son diferentes, el problema se reproduce_
image

_Edición reproducida_
image

Hola @ tomSauret847

¿Todavía necesitamos tener una conexión de autenticación en cada habilidad con las habilidades de mecanografiado?

Debe tener una conexión de autenticación en cada habilidad de TypeScript hasta que se lance la versión 1.0 de la habilidad de TypeScript.

¿O podemos usar el SSO único como se describe para las habilidades de C #?

No se puede usar SSO para TypeScript como se describe para las habilidades de C #, ya que la versión 1.0 de TypeScript aún no se ha lanzado.

Háganos saber si esto le ayuda 😊.

@ tomSauret847 - el error Error: Could not find Connection Setting with name {connection name} se debe a que la propiedad name en oauthConnections de appsettings difiere de la propiedad connectionName en OAuthPromptSettings que estás usando.

Para solucionar esto, debes comprobar que ambas propiedades sean iguales .

Para obtener más información, puede consultar el comentario de arriba.

Gracias @ Batta32 por investigar esto. Puedo confirmar que si creo una propiedad de conexión en la habilidad, puedo obtener el mensaje de inicio de sesión. Tu comentario ha hecho surgir otra pregunta. Nos estamos preparando para pasar a las pruebas con nuestro nuevo VA y luego a la producción. La pregunta que tengo

¿Esta solución para la autenticación se publicará en NPM antes de la versión 1.0?

Para nuestro entorno de producción, necesitaremos paquetes NPM publicados, por lo que necesitaríamos que esta corrección se publique antes de poder mover este VA a producción. Estaré atento a tu respuesta.

@ tomSauret847 - ¡Gracias por su respuesta! Estamos agregando estas correcciones en los PR de la versión 1.0 de TypeScript:

  • PR # 3583: [TypeScript][Bot-Solutions] Implement changes in Bot-Solutions to 1.0 release
  • PR # 3584: [TypeScript][Virtual Assistant] Implement changes in Virtual Assistant to 1.0 release
  • PR # 3585: [TypeScript][Skill] Implement changes in Skill to 1.0 release

Le informaremos tan pronto como tengamos alguna actualización al respecto. Mientras tanto, estamos trabajando en la validación del proceso de Autenticación en TypeScript.

@ tomSauret847 : identificamos otro problema de que la variable Skill State estaba _undefined_ durante el proceso de autenticación.

Tomamos como guía el PR # 3561 que establece un valor predeterminado para el descriptor de acceso Skill State que incorporamos en este compromiso .
Después de aplicar estos cambios, el proceso de autenticación funciona correctamente. Este problema se solucionará tan pronto como se fusione TypeScript v1.0.

Este es nuestro entorno usando esta rama : feature/southworks/test-fix-auth-skill :

Mientras tanto, si desea una forma de probar la solución por sí mismo, puede seguir estos pasos:

  1. Vaya a la carpeta bot-solutions
  2. Ejecute npm install para instalar sus dependencias.
  3. Ejecute npm run build para construir la solución.
  4. Ejecute npm pack para generar un archivo .tgz. Debería crear un archivo en la misma ubicación, llamado bot-solutions-version.tgz
  5. Vaya a la carpeta Skill Sample
  6. Apunte al tgz generado en el bot de muestra de habilidad, reemplazando la referencia de soluciones de bot en el paquete.json del bot de "bot-solutions": "^1.0.0" a "bot-solutions": "<PATH_TO_TGZ>"
  7. Ejecute npm install para instalar sus dependencias.
  8. Ejecute npm run build para construir la solución.
  9. Validar el proceso de autenticación

Estamos atentos a tu respuesta. 😊

_La variable SkillState obtiene un valor indefinido_
image

_Proceso de autenticación funcionando correctamente_
image

¡Gracias de nuevo @ Batta32! Usé el paquete

@ Batta32 Hemos configurado la autenticación en 2 de nuestras habilidades y está funcionando bien en el canal de Teams. El canal de línea directa no pasa la solicitud de autenticación. La habilidad no recibe el token nuevamente después de iniciar sesión correctamente. Este problema solo está presente en nuestro canal de línea directa. Estamos utilizando el cliente de línea directa de muestra que se proporcionó y habilitó las opciones de autenticación mejoradas para que no ingresemos el "código mágico". Funcionó antes de agregar la autenticación mejorada, pero después de agregar esta función, la habilidad ya no recibe la respuesta del token. Si cancelamos la habilidad y volvemos a ese diálogo, el token estará presente y podremos completar el diálogo. Avíseme si tiene alguna idea sobre lo que podría estar causando esto.

Gracias @ tomSauret847 , estaremos revisando ese escenario y te responderemos tan pronto como podamos.

Solo para comenzar a revisar el escenario:

  1. ¿Qué quiere decir con "ejemplo de cliente de línea directa"?
  2. ¿Qué cliente estás usando?
  3. ¿Qué quieres decir con "Código mágico"?

Gracias de nuevo @ Batta32 por investigar esto. Estamos utilizando la muestra de línea directa del repositorio de soluciones botbuilder que se encuentra aquí
El "código mágico" se explica algo en esta pregunta de desbordamiento de pila aquí
Es solo el código que el usuario del bot debe copiar y pegar en la conversación después de autenticarse con éxito. Al implementar la autenticación mejorada, se elimina este paso para el usuario del bot, por lo que solo necesitan autenticarse y la conversación avanza a medida que el token se devuelve al bot detrás de escena.

Muchas gracias @ tomSauret847 , lo

Hola @ tomSauret847 , no pudimos reproducir este problema porque tenemos el escenario de autenticación funcionando correctamente.

Se te ocurrieron algunas preguntas :

  1. ¿Ha comprobado si este problema ocurre hablando directamente con la habilidad, sin conectarse a un asistente virtual?
  2. Si va a pasar por un VA para conectarse al Skill, ¿también está habilitando el canal Directline en el VA? ¿Qué más ha configurado, autenticación de Azure AD v2, autenticación mejorada?
  3. ¿Qué quieres decir con "Si cancelamos la habilidad y volvemos a ese cuadro de diálogo, el token estará presente y podemos completar el cuadro de diálogo"?

Esta es la configuración que hemos estado usando:

  • Una habilidad de TypeScript creada con el [email protected]
  • Configuración de autenticación de tipo Azure AD v2 en esa habilidad
  • Canal de línea directa habilitado con autenticación mejorada en la habilidad
  • La muestra web de Directline del repositorio establecido en un ID de usuario específico ("dl_xxxx")
  • El appsettings.json en el cliente de Directline se configuró de manera similar a esto:
{
    "Logging": {
        "LogLevel": {
            "Default": "Warning"
        }
    },
    "AllowedHosts": "*",
    "BotName": "skillbot-name",
    "DirectLineSecret": "XXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "EnableDirectLineEnhancedAuthentication": true,
    "SpeechServiceRegionIdentifier": "",
    "SpeechServiceSubscriptionKey": ""
}

Los pasos que seguimos son:

  1. Ponerse en contacto con la habilidad a través del cliente de Directline
  2. Invocar el cuadro de diálogo de inicio de sesión ("ejecutar cuadro de diálogo de muestra")
  3. Hacer clic en el botón de inicio de sesión (no es necesario el "código mágico")
  4. Iniciamos sesión con éxito y el bot nos saluda
  5. A partir de ese momento, cada vez que repetimos los pasos 1 y 2, automáticamente iniciamos sesión y el bot nos saluda.

Estaremos atentos a tu respuesta.

Gracias @ matiasroldan6 por investigar esto. Para responder tu pregunta

  1. No podemos comunicarnos con la habilidad directamente, ya que la tenemos dentro de una red virtual, por lo que los canales no pueden acceder a ella.
  2. Estamos llegando a la habilidad a través del VA y tenemos el canal de línea directa configurado solo en el VA. Estamos usando la autenticación de Azure AD V2 en las propiedades de conexión en Skill y VA. Tenemos la autenticación mejorada configurada en el VA
  3. si completamos el inicio de sesión cuando se nos presente la tarjeta de inicio de sesión. El bot se colgará y no avanzará. Si cancelamos, luego regresamos a una habilidad que tiene autenticación, tiene el token y omite el indicador de inicio de sesión y nos permite continuar. Tenemos 2 habilidades con la autenticación y si nos autenticamos en una, también nos autenticamos en la segunda.
    aquí hay una captura de pantalla de nuestra configuración para el canal de línea directa en el VA
    image

Tenemos el ID de usuario configurado en "dl_xxxx" en el cliente de línea directa
Tenemos la autenticación de Azure AD v2 en la conexión en el Skill y VA
Tenemos el archivo appsettings.json del cliente de línea directa configurado igual que el anterior
No podemos usar el canal de línea directa en la habilidad y solo lo usamos en el VA
Podemos usar la autenticación en el canal de Teams con el único problema es que los mensajes de diálogo están fuera de servicio. No se envía el primer stepContext.context.sendActivity ('mensaje') hasta un minuto más tarde en la conversión. Esto solo ocurre en los cuadros de diálogo que tienen autenticación incluida en ellos y solo en el canal de Teams.
Estamos usando el bot-solutions 1.0 que se encuentra aquí.

Por favor, avíseme si necesita más información sobre la habilidad y VA

Hola @ tomSauret847 , podríamos reproducir una ocurrencia de este problema.
En nuestro escenario, el problema fueron las direcciones de origen confiables establecidas en el canal Directline. Por ejemplo, la ventana emergente Directline indica que los orígenes de confianza deben ser _https_ o _http_ para _localhost_. Esto explicaría a Directline como el único canal que le está fallando.

Para verificar en caso de que este también sea su problema, puede intentar establecer como orígenes confiables:
La dirección de su bot (ya sea https://xxxxx.azurewebsites.net o https://xxxx.ngrok.io si está depurando localmente)
Su localhost si lo necesita, como http: // localhost
image

La configuración para reproducir esto fue:

  • Un asistente virtual 1.0 con

    • Bot-Solutions 1.0 en las dependencias

    • Autenticación de Azure AD v2 habilitada

    • Canal de línea directa habilitado con autenticación mejorada en

    • Orígenes de confianza en el canal Directline establecido en https: // localhost : xxxx (siendo _xxxx_ la dirección del cliente Directline) y la dirección del bot (https://xxxxx.azurewebsites.net o https://xxxx.ngrok.io para conexiones locales ). Hicimos esto emulando la configuración de la imagen que adjuntaste en tu último mensaje.

  • Una habilidad 1.0 con

    • Bot-Solutions 1.0 en las dependencias

    • Autenticación de Azure AD v2 habilitada

    • Conectado al Asistente Virtual.

  • El cliente web Directline configurado con identificación de usuario y autenticación mejorada con la misma configuración de nuestro mensaje anterior.

Nuestros pasos de reproducción fueron:

  1. Conecte la muestra de Directline al Asistente.
  2. Intente activar la autenticación ("ejecutar diálogo de muestra").
  3. Aparece el cuadro de diálogo Autenticación, pero después de hacer clic en el botón no sucede nada y el bot no responde, incluso a los intentos posteriores de invocar la autenticación.
    image
  1. Cancele el flujo y luego vuelva a ejecutar los pasos 1 y 2, luego nos autenticamos automáticamente y el bot nos saluda.

Háganos saber si esto es de alguna ayuda. Estaremos atentos a tus respuestas.

Gracias @ matiasroldan6 por investigar esto. La configuración que muestra arriba es la misma que estamos usando. Eliminamos la ruta localhost y solo tenemos la dirección del bot en los orígenes confiables para el canal de línea directa (https://xxxxx.azurewebsites.net). La habilidad aún no responde después de la indicación de inicio de sesión y si cancelamos la conversación e invocamos la habilidad nuevamente, tendrá el token y continuará el diálogo. Todavía no podemos obtener la habilidad para recibir el token después de que el usuario inicie sesión.

Gracias por su respuesta @ tomSauret847 .

Tenemos preguntas para entender cómo está utilizando el punto final azurewebsites.net teniendo en cuenta la versión 1.0 de bot-solutions (PR # 3583):

  1. ¿Está utilizando el Messaging endpoint de su bot de aplicación web publicado (Asistente virtual)?
  2. ¿Cómo integró la versión 1.0 de las soluciones bot en su Asistente Virtual y Habilidad publicados? Entendemos que utilizó el paquete .tgz de la biblioteca. ¿Es esto correcto?
  3. ¿Existe alguna posibilidad de probar utilizando el punto final localhost configurándolo como se indicó anteriormente en la configuración del Canal de línea directa?

Gracias @ Batta32

  1. Estamos utilizando el punto final de mensajería del VA en la configuración de host de confianza.
  2. estamos usando el paquete .tgz que fue clonado de la versión 1.0. Eliminamos la carpeta node_modules y los archivos package-lock.json antes de pasar al paquete .tgz. Luego actualizó el archivo package.json y luego ejecutó la instalación de npm
  3. Probamos con el host local y recibimos la misma respuesta. Todavía no podemos hacer que el token pase a través de la conversación, pero cuando el diálogo se cancela y se inicia de nuevo, el token está presente.

Gracias @ tomSauret847 , continuaremos revisando este problema con esta nueva información que proporcionaste. Tan pronto como tengamos alguna actualización, te responderemos 😊.

Hola @ tomSauret847 , reproducimos con éxito una ocurrencia de este problema.

Una cosa que notamos de sus respuestas anteriores es que está utilizando la URL de su bot como un origen confiable.
Según este comentario y esta documentación , debe tener la URL de su cliente de chat.
image

Nuestra configuración fue:

Pasos:

  1. Utilice el cliente web de Directline para ponerse en contacto con el Asistente virtual
  2. Invocar la habilidad ("ejecutar diálogo de muestra")
  3. Que la habilidad le presente el botón de autenticación, haga clic en él (no pasa nada)
  4. Repetir el paso 2 nos autentica automáticamente, sin mostrar el botón de autenticación.

Continuaremos revisando este problema ya que confirmamos y como mencionaste, que en Microsoft Teams y Emulator esto está funcionando.
image

Hola @ tomSauret847 , éxito el proceso de autenticación mediante Autenticación mejorada.

Se nos ocurrieron algunas preguntas para que puedas consultar nuestro lado:

  1. ¿Puede verificar si tiene las carpetas publicadas de los bots implementados accediendo en Kudu (https: //.scm.azurewebsites.net / ZipDeployUI) reemplazando <WEB_APP_BOT_NAME> con el nombre de su recurso de bot? Compruebe si tiene node_modules , lib y el resto de carpetas.
  2. ¿Puede comprobar si el punto final de mensajería de los bots es el punto final de producción (azurewebsites.net)?
  3. ¿Ha conectado el Asistente virtual a las habilidades utilizando el punto final de producción?
  4. ¿Puede comprobar si puede acceder al manifiesto de habilidades de la habilidad publicada? Si no es así, agregue los cambios del PR # 3601

Este es nuestro entorno :

Seguimos estos pasos :

  1. Aplicar los cambios del PR # 3601 en la Habilidad
  2. Cree una carpeta para almacenar el archivo Bot-Solutions 1.0 .tgz en ambas muestras
  3. Señale la referencia de las soluciones de bot al tgz local, como "bot-solutions": ".//TGZ//bot-solutions-1.0.0.tgz" de los bots
  4. Implemente los bots usando deploy.ps1
  5. Conecte ambas muestras con Botskills usando el RemoteManifest
  6. Configure los ajustes de conexión de OAuth de ambas muestras con un AADv2
  7. Configure oauthConnections en la configuración de la aplicación de cada muestra
  8. Publique ambas muestras usando el script publish.ps1
  9. Activar el canal Directline en el Asistente virtual
  10. Habilite la autenticación mejorada en la línea directa del asistente virtual
  11. Conecte la muestra de Directline al Asistente virtual

    1. Nota : actualice esta línea a un GUID estático si desea conservar la conversación

  12. Finalmente, active la autenticación usando run sample dialog
  13. Después de iniciar sesión, la habilidad le pedirá un nombre
  14. Verifique que la autenticación mejorada funcione correctamente

Por último, pero no menos importante, confirmamos los mismos pasos usando bots de C # y verificamos que también funciona correctamente.

Estaremos atentos a tu respuesta 😊

_Configuración de la autenticación mejorada_
image

_Comunicación exitosa usando Autenticación mejorada y bots de TypeScript_
auth fixed

_Comunicación exitosa usando autenticación mejorada y bots de C #_
image

Gracias @VictorGrycuk. Perdón por la respuesta tardía que necesitábamos para configurar una instancia de prueba para verificar la corrección. Hemos podido hacer que la autenticación funcione en la instancia de prueba y hemos reducido dónde está el problema.

Para nuestra instancia de VA / Skills, los tenemos detrás de una puerta de enlace de aplicaciones con un firewall. Parece que esta es la razón por la que la autenticación mejorada no funciona. Cuando implementamos esto en un VA y una habilidad fuera de esa configuración, está funcionando correctamente. la puerta de enlace de la aplicación coloca otro host en la mezcla y creemos que esto es lo que está bloqueando el token. Entonces tenemos la siguiente pregunta,

¿Hay alguna manera de hacer que la autenticación mejorada funcione con un bot detrás de una puerta de enlace de aplicaciones?

¡Genial @ tomSauret847! Haremos una investigación y algunas pruebas para revisar una forma de hacer que la autenticación mejorada funcione con un bot detrás de una puerta de enlace de aplicaciones.

Tan pronto como tengamos alguna actualización para esto, se lo haremos saber aquí 😊.

Hola @ tomSauret847 , investigamos un poco y se nos ocurrieron algunas preguntas .

  1. ¿Está probando con los bots implementados en Azure o en el servidor de promises?
  2. ¿Es su puerta de enlace de aplicaciones una puerta de enlace de aplicaciones de Azure ?
  3. ¿Estás usando bots de TypeScript o C #? Como mencionaste anteriormente, hiciste la transición a los bots de C #.

Estaremos atentos a tu respuesta 🙂

Gracias por responder @VictorGrycuk aquí están las respuestas a nuestras preguntas,

  1. Estamos probando con los bots implementados en Azure. No podemos crear un túnel para realizar pruebas de forma local.

  2. Sí, estamos usando una puerta de enlace de aplicaciones de Azure con un WAF como se describe en su enlace

  3. Estos son bots de TypeScript (VA y 2 habilidades con autenticación), solo estamos usando 1 habilidad de C # para solucionar el problema del bucle síncrono y no tiene autenticación.

Hola @ tomSauret847 , perdón por la demora; creemos que debería ser posible usar la autenticación mejorada con una puerta de enlace de aplicaciones de Azure con los bots detrás.

Un par de preguntas adicionales:

  1. ¿Puede conectarse al Asistente virtual con un emulador utilizando la IP pública de la puerta de enlace? En nuestras pruebas confirmamos que esto es posible
  2. ¿Puede conectarse y comunicarse con una habilidad a través del VA sin una comunicación mejorada?

Componentes :

Configuración :

  • Asistente virtual con autenticación mejorada, como se explica en este comentario
  • La Habilidad conectada al Asistente Virtual configurada con la autenticación
  • Línea directa como se configuró en el mismo comentario que arriba
  • Application Gateway apuntando al bot implementado como se explica en este artículo

Trabajaremos para replicar este escenario.

Gracias @VictorGrycuk Las respuestas a sus preguntas son
¿Puede conectarse al Asistente virtual con un emulador utilizando la IP pública de la puerta de enlace? En nuestras pruebas confirmamos que esto es posible

  • No tenemos tunelización disponible y no podemos conectarnos al VA con un emulador, pero tenemos chat web disponible. El VA se conectará a la habilidad y completará los diálogos.

¿Puede conectarse y comunicarse con una habilidad a través del VA sin una comunicación mejorada?

  • Sí, si no usamos la Autenticación mejorada podemos copiar y pegar el código y la autenticación funciona como se esperaba. Nos gustaría la integración perfecta que la autenticación mejorada proporciona a nuestros usuarios.

Hola @ tomSauret847 , podemos confirmar que la autenticación mejorada funciona con los bots detrás de Azure Application Gateway.

Creamos el PR # 3694 que incluye una nueva documentación sobre cómo configurar Azure Application Gateway con un bot implementado.

Hicimos nuestra prueba siguiendo estos pasos :

  1. Siga los pasos descritos en este comentario para implementar bots con autenticación mejorada
  2. Siga los pasos detallados en el documento Configuración de la sonda de estado de una puerta de enlace con un bot de TypeScript para conectar el Asistente virtual implementado al grupo de backend de Azure Application Gateway.
  3. Pruebe el inicio de sesión de la habilidad implementada con el ejemplo de Directline
  4. La autenticación mejorada funcionó y el diálogo de muestra de habilidad continuó como se esperaba

Como esto parece un problema de configuración de Azure Application Gateway, le sugiero que solicite sugerencias en https://stackoverflow.com/questions/tagged/botframework ; y si está bien, podemos cerrar este problema 🙂.

Gracias @VictorGrycuk Trabajaremos a través de la información que publicó. Ya me di cuenta de que este enlace está roto.

Gracias @ tomSauret847 , ese enlace conducirá a la configuración de la sonda de salud de una puerta de enlace con un bot de TypeScript (así como esta imagen ) una vez que los documentos se combinen en la rama master , ya que la documentación usa {{site.baseurl}} para generar las URL.

@peterinnesmsft : podemos cerrar el problema debido a la inactividad. @ tomSauret847 si aún tiene problemas, no dude en reactivarlo y podemos

Además, si tiene alguna pregunta, pregunte en https://stackoverflow.com/questions/tagged/botframework.

Todo el proceso de autenticación se resolverá tan pronto como se fusionen los siguientes PR para la versión 1.0 de TypeScript:

  • PR # 3583: [TypeScript][Bot-Solutions] Implement changes in Bot-Solutions to 1.0 release
  • PR # 3584: [TypeScript][Virtual Assistant] Implement changes in Virtual Assistant to 1.0 release
  • PR # 3585: [TypeScript][Skill] Implement changes in Skill to 1.0 release

Gracias @ Batta32 por su ayuda en esto. Tenemos que poner esta sección en espera por el momento, así que cerraré este problema y volveré a abrirlo si tenemos problemas cuando lo retomemos nuevamente.

@ Batta32 Tenemos una pregunta rápida sobre este tema. ¿Ya está disponible el SSO para mecanografiado? Descubrimos que el problema es que nuestras habilidades están detrás de un firewall y no pueden recibir la respuesta del token. Cuando pasamos las credenciales de la VA, no está reenviando el token a la habilidad, solo está reiniciando la conversación. Si el SSO para mecanografiado no está disponible, ¿cuándo lo espera? Gracias por toda su ayuda en este tema.

Hola @ tomSauret847 , SSO no está disponible para TypeScript actualmente, ya que se presentó en la versión 1.0. Los PR de la versión 1.0 de TypeScript deben aprobarse y fusionarse para poder lanzar una nueva versión con esa característica.

Te avisaremos tan pronto como tengamos alguna actualización 😊.

¿Fue útil esta página
0 / 5 - 0 calificaciones