Asistente virtual y habilidad de TypeScript
Mecanografiado
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.
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.
en Generator.next (
en D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ waterfallDialog.js: 7: 71
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
Reciba la tarjeta de inicio de sesión para iniciar sesión
Error: DialogContext.beginDialog (): no se encontró un cuadro de diálogo con un ID de 'AuthPrompt'.
en WaterfallStepContext.
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.
en Generator.next (
en D: \ home \ site \ wwwroot \ node_modules \ botbuilder-dialogs \ lib \ waterfallDialog.js: 7: 71
¡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:
OAuthPromptSettings
matriz para el MultiProviderAuthDialog
constructorappsettings.oauthConnections
a las propiedades de botSettings
AADv2
AADv2
para el registro en AzureTan pronto como tengamos alguna actualización, te responderemos 😊.
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 :
npm install
para instalar sus dependencias.npm run build
para construir la solución.npm pack
para generar un archivo .tgz
. Debería crear un archivo en la misma ubicación, llamado bot-solutions-version.tgz"bot-solutions": "^1.0.0"
a "bot-solutions": "<PATH_TO_TGZ>"
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:
name
en oauthConnections
de appsettings.json
difiera de la propiedad connectionName
en el OAuthPromptSettings
que está utilizando_Cuando el nombre de conexión y el nombre son diferentes, el problema se reproduce_
_Edición reproducida_
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:
[TypeScript][Bot-Solutions] Implement changes in Bot-Solutions to 1.0 release
[TypeScript][Virtual Assistant] Implement changes in Virtual Assistant to 1.0 release
[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:
npm install
para instalar sus dependencias.npm run build
para construir la solución.npm pack
para generar un archivo .tgz. Debería crear un archivo en la misma ubicación, llamado bot-solutions-version.tgz"bot-solutions": "^1.0.0"
a "bot-solutions": "<PATH_TO_TGZ>"
npm install
para instalar sus dependencias.npm run build
para construir la solución.Estamos atentos a tu respuesta. 😊
_La variable SkillState obtiene un valor indefinido_
_Proceso de autenticación funcionando correctamente_
¡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:
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 :
Esta es la configuración que hemos estado usando:
{
"Logging": {
"LogLevel": {
"Default": "Warning"
}
},
"AllowedHosts": "*",
"BotName": "skillbot-name",
"DirectLineSecret": "XXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"EnableDirectLineEnhancedAuthentication": true,
"SpeechServiceRegionIdentifier": "",
"SpeechServiceSubscriptionKey": ""
}
Los pasos que seguimos son:
Estaremos atentos a tu respuesta.
Gracias @ matiasroldan6 por investigar esto. Para responder tu pregunta
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
La configuración para reproducir esto fue:
Nuestros pasos de reproducción fueron:
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):
Messaging endpoint
de su bot de aplicación web publicado (Asistente virtual)?.tgz
de la biblioteca. ¿Es esto correcto?Gracias @ Batta32
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.
Nuestra configuración fue:
Pasos:
Continuaremos revisando este problema ya que confirmamos y como mencionaste, que en Microsoft Teams y Emulator esto está funcionando.
Hola @ tomSauret847 , éxito el proceso de autenticación mediante Autenticación mejorada.
Se nos ocurrieron algunas preguntas para que puedas consultar nuestro lado:
<WEB_APP_BOT_NAME>
con el nombre de su recurso de bot? Compruebe si tiene node_modules
, lib
y el resto de carpetas.Este es nuestro entorno :
Seguimos estos pasos :
.tgz
en ambas muestras"bot-solutions": ".//TGZ//bot-solutions-1.0.0.tgz"
de los botsdeploy.ps1
publish.ps1
run sample dialog
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_
_Comunicación exitosa usando Autenticación mejorada y bots de TypeScript_
_Comunicación exitosa usando autenticación mejorada y bots de C #_
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 .
Estaremos atentos a tu respuesta 🙂
Gracias por responder @VictorGrycuk aquí están las respuestas a nuestras preguntas,
Estamos probando con los bots implementados en Azure. No podemos crear un túnel para realizar pruebas de forma local.
Sí, estamos usando una puerta de enlace de aplicaciones de Azure con un WAF como se describe en su enlace
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:
Componentes :
Configuración :
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
¿Puede conectarse y comunicarse con una habilidad a través del VA sin una comunicación mejorada?
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 :
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:
[TypeScript][Bot-Solutions] Implement changes in Bot-Solutions to 1.0 release
[TypeScript][Virtual Assistant] Implement changes in Virtual Assistant to 1.0 release
[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 😊.
Comentario más útil
¡Gracias de nuevo @ Batta32! Usé el paquete