microsoft
oAuthcard | botframework-webchat: 4 seconds delay after succesfull login
Is it an issue related to Adaptive Cards?
No
Is this an accessibility issue?
No
What version of Web Chat are you using?
Latest production (4.16.0)
Which distribution are you using Web Chat from?
Unrelated
Which hosting environment does this issue primarily affect?
Web apps
Which browsers and platforms do the issue happened?
Others or unrelated
Which area does this issue affect?
Attachment: OAuth card
What is the public URL for the website?
No response
Please describe the bug
After the authentication process of the oAUTH card finishes, there is a long delay before the next messages are rendered. I was able to reproduce it using the sample 18. not-authentication using NodeJS and bot emulator.
Do you see any errors in console log?
queueIncomingActivitySaga.js:178 botframework-webchat: Timed out while waiting for activity "60fb1610-b9d3-11ee-9214-55ee94be6ec6" which activity "60fc9cb0-b9d3-11ee-9214-55ee94be6ec6" is replying to. {activity: {…}, replyToId: "60fb1610-b9d3-11ee-9214-55ee94be6ec6"}activity: {type: "message", serviceUrl: "http://localhost:52975", channelId: "emulator", from: {…}, conversation: {…}, …}replyToId: "60fb1610-b9d3-11ee-9214-55ee94be6ec6"__proto__: Object
(anonymous) @ queueIncomingActivitySaga.js:178
u @ runtime.js:63
How to reproduce the issue?
I used Node v16.16.0 Emulator is 4.14.1 Also testen with latest production release [4.16.0]
Follow all steps for javascript in Add authentication to a bot Press login and enter your details. When login is succesfull you will notice that the message activities You are now logged in and the other arrive right away but are rendered only 4 seconds later In the console you will see the messages mentioned above
What do you expect?
I expect the message activities to be rendered right away The current behavior results in users clicking on the login button multiple time and expecting the authentication failed.
What actually happened?
When login is succesfull it takes another 4 seconds or so before new activities are rendered
Do you have any screenshots or recordings to repro the issue?
No response
Adaptive Card JSON
No response
Additional context
No response
Hi @stevkan, sorry to reach out to you like this. Not sure if webchat is still getting updates etc. If so, I noticed you solved a similar issue like the one I am facing.
@HesselWellema - Regarding testing, have you only tested this in Emulator? I see you mention having used the latest production release (v4.16.0). Does that mean you tested with one of the Web Chat samples? If so, could you tell me which one and/or could you share a copy of your Web Chat code? I just want to attempt a repro as closely to your setup as possible.
As for Emulator, are you utilizing ngrok at all (configured within the app or without)?
@stevkan tx for replying. I noticed the issue with my own webchat code (^4.14.0). Because I wanted to make sure it is reproducable for you guys I used the emulator (4.14.1) which I thought was also webchat and a sample code for the bot setup (18.bot-authentication) I am getting exactly the same error in this local setup as when everything is running on azure. For the emulator the box for Bypass ngrock for local addresses is ticketd and the Tunnelstatus is inactive. Also the box 'use a sign-in verification code for oAuthcards is ticked' In the Azure bot I use directline v3 with Enhanced authentication options enabled and trusted origins added for the local adresses.
If you need me to reproduce using a webchat sample, I will. Let me know thank you
@stevkan Also tested on one of the webchat samples. The full featured bundle which is using https://cdn.botframework.com/botframework-webchat/latest/webchat.js I used my own botcode. Same behavior, slightly different error in console
webchat.js:2 botframework-webchat: Timed out while waiting for activity "8fbc321d-cb2a-4b17-9fe9-bca0a9978975" which activity "GznnJMwpRHsKRZ4O2NHykp-eu|0000003" is replying to. {activity: {…}, replyToId: '8fbc321d-cb2a-4b17-9fe9-bca0a9978975'} activity : channelId : "directline" conversation : {id: 'GznnJMwpRHsKRZ4O2NHykp-eu'} from : {id: '<>', name: 'Bot', role: 'bot'} id : "GznnJMwpRHsKRZ4O2NHykp-eu|0000003" inputHint : "acceptingInput" replyToId : "8fbc321d-cb2a-4b17-9fe9-bca0a9978975" text : "<test message from bot>" timestamp : "2024-02-01T08:42:45.223224Z" type : "message" [[Prototype]] : Object replyToId : "8fbc321d-cb2a-4b17-9fe9-bca0a9978975" [[Prototype]] : Object
The error is allways on the first event sent by the bot in the waterfall step after the oAuth prompt.
Hi @stevkan, just a friendly reminder. Is this something that we should be able to solve? This 'behavior' is preventing us from implementing oAuth.
Maybe @OEvgeny are you able to help validate if this is a bug? This is preventing us from implementing oAuth authentication for bot in a corporate environment
I was able to reproduce the issue on my end. Looks like the delay is caused by the wrong replyToId set for the activities going after the successful signin flow.
WebChat is waiting for an activity with the id to appear and that's why it delays showing the messages until the timeout is reached. This looks like a broken promise from the SDK side as the replyToId field should either contain the message id or be omitted.
I see there's already https://github.com/microsoft/botbuilder-js/issues/4595 suggesting disabling the card as a workaround for now.
Thanks for you effort to do the repro @OEvgeny. Is this an issue on the implementation of the oAuth card in webchat or a issue at the SDK end. What team do you think should solve this.
@HesselWellema to me this issue doesn't look like the WebChat issue as we are not able to influence the generation of the non-existent or malformed replyToId ids. I suppose we also won't be able to filter out ids which may not correspond to any activity as different bot implementations may have different id values generation patterns which would limit WebChat usage and likely introduce new bugs.
I think Bot Framework SDK shouldn't send the malformed or non-existent ids in the replyToId field in the first place. The field is designed to carry information regarding related activity in the current conversation and can be omitted according to the spec. As the wrong ids comes from the bot which is using Bot Framework SDK for JavaScript, I suppose the issue may have a fix on their end.
I wasn't able to track down the issue in the repo though. All uses of replyToId seen are referencing the activity, so there may be something else involved.
Some additional information. This behavior (the 4 second delay) does not occur without advanced authentication enabled in the directLine channel. WHen the authentication code is entered by the user, the next step in the waterfall is executed instantly. But asking users to enter a code after they have used an authentication device (in our case) is also not a good user experience
Hi @stevkan and @OEvgeny. Is this still on your radar guys? I am a bit lost now. Do I need to ask the SDK team to look into this or is it something that could be solved in the webchat code.
Hi @compulim. Would really appreciate some guidance here. The issue above is easy reproduceable but it is unclear if it should be solved in the SDK or in the webchat code. We really need authentication in one of our bots and if this will not work, I will look into other options to add authentication. No is also an answer ;-)
Hello @HesselWellema sorry for a delay, I was sick yesterday. Nothing new from my end yet: I believe this is an SDK issue, not the WebChat issue, but I wasn't able to track the issue on the SDK side.
Please refer to my previous message for more details regarding on why the issue happens. Given WebChat's flexibility there might be a way to filter out the wrong replyToId ids on your side. I haven't tried this approach yet though
tx @OEvgeny . I apologize for stalking you guys like this, but I'm quite stuck. My modifications to webchat are generally limited to tweaking the interface. Therefore, I wouldn't even know where to start with filtering reply-to IDs, not to mention that I don't understand the consequences. I would rather not touch it. If you could help us, that would be greatly appreciated. Either with a clear problem description for the SDK team or a workaround in the webchat itself.
Team. I spend another couple of hours on this but cant get my head around it and it is getting frustrating (same for the users of these chatbots because it is a very annoying experience). Could you please explain what do do or at least explain to us the formal status of the Bot Framework Webchat product. Can we still expect maintenance or should we accept it as is.
Wrt the issue had hand. It is easily reproducible with samples. It is not clear to me if the solution should be implemented on the webchat side or in the SDK side. Both teams are pointing in the other direction and we are lost
Closing this issue. I decided to move away from the oAuth prompt and implement authentication outside of webchat