Can't get sample 18 to work without using a magic code

[JonathanFingold]

Version

What version of the Emulator are you using: 4.4.1

Describe the bug

When I try to run the 18.Bot-authentication sample, it didn't work correctly, until I checked the Use a sing-in verification code for OAuthCards emulator setting, forcing the use of a magic code. However, the point of the sample is to show how to avoid the need for a magic code.

To Reproduce

Steps to reproduce the behavior:

1. Register an Azure AD v1 app for use with the No x86_32 Build #18 bot. (I haven't tried reproducing with a v2 app yet.)
2. Create a channels registration bot and add an OAuth connection for the v1 app.
3. Update the appsettings.json file for the bot.
4. Run the bot locally.
5. Attach to it in the Emulator, using the bot's app ID and password. (Use the http:// endpoint.)
6. Attempt to exercise the bot and log in.
7. Error: The log in flow never completes correctly. (It should ask if you want to see your token.)
8. Select the Use a sing-in verification code for OAuthCards emulator setting and restart the emulator.
9. Try connecting to the bot again and logging in.
10. You get a magic code to use, but now the bot appear to otherwise work correctly, in that you are asked if you want to see your token.

Expected behavior

We shouldn't have to use a magic code to get this sample to work correctly.

Screenshots

Here's the bot behavior with using the magic code:

Additional context

1. I've been trying to get this to work with help from @EricDahlvang and @mingweiw.
2. This issue means the current authentication how-to documentation is in error and is blocked from being corrected.

[bug]

[tonyanziano]

Hmm, this is interesting. I took a look at the history of the code affected by the verification code checkbox, and it hasn't been touched in over a year.

This isn't a scenario we test often, but it seems unlikely to me that we would have recently introduced a bug that would affect this flow.

[JonathanFingold]

The Azure UI for creating AAD app registrations changed very recently. There appears to be some untoward interaction between Azure, the sample, and the Emulator that I have not been able to narrow down further.

I don't think the code for the check box broke anything. It's just that it is providing a work around for whatever is broken.

[v-kydela]

An event activity with a token is supposed to be sent to the bot to indicate that the user has signed in successfully. This does not happen in 4.4.1. When the user signs in, the bot is not notified.

[stevkan]

What @v-kydela describes predates version 4.4.1. I spoke with @Jeffders some few months ago regarding some OAuth questions I had in which this topic came up. His explanation suggested that this was the known, if not expected, behavior. Without the magic code, the user needs to prompt the bot with another comment in order for the dialog to continue normally.

[v-kydela]

I do remember having this problem in older versions, but authentication without the magic code worked in 4.4.0. The problem seems to have been reintroduced in 4.4.1.

[JonathanFingold]

Ming was able to get the sample to work in the v3 emulator, the issue appears to be in the v4 emulator (as opposed to the sample code or the Azure service).

[v-kydela]

Can the responsible party please label this as a bug?

[tonyanziano]

I now have some cycles to take a look at this and investigate what's going on.

[tonyanziano]

After some investigation I've figured out the problem, and I have a workaround that should be sufficient until we get a fix into master.

TLDR; Uncheck the "Bypass ngrok for local addresses" option in the app settings as a workaround for now, and OAuth prompt cards should work.

===

The Problem:

In both V3 and V4 of the Emulator, we have the option to bypass ngrok for bots running on localhost.

When we go through the OAuth flow, after the user has signed in through Microsoft, we contact the Bot Framework token server with a postback URL that the token server can send the newly generated access token to.

In V3, we always have a running ngrok URL that we use as the postback URL, so that when the token server grants us a token, it sends it to this ngrok URL (the Emulator) that the Emulator then sends to the bot, completing the auth flow.

However, in V4, when we have "Bypass ngrok for localhost" enabled, we instead send the actual Emulator localhost service url as the postback URL, which the token server tries to contact, but cannot, because there is no tunnel from the user's machine to the token server. Therefore, the token never makes it back to the Emulator, thus the Emulator never sends the token back to the bot.

Temporary Workaround

To get around this until we merge a fix into master, you can go to app settings and uncheck the "Bypass ngrok for local addresses" option and save your settings.

Working

[JonathanFingold]

I'll put a comment in for now in the authentication how to to this effect.

[EricDahlvang]

V3 had both of these settings too:

Can we require "Use a sign-in verification code for OAuthCards" if "Bypass ngrok for local addresses" is checked?

[v-kydela]

@EricDahlvang - That may be unnecessary if this issue can be fixed. Tony said the workaround is temporary.

[tonyanziano]

@EricDahlvang V4 has those options as well; you can see them in my above screenshot under the "User Settings" header.

As Kyle said, if the root cause can be fixed then we will do that, otherwise I believe your solution would work as well.

[v-kydela]

@tonyanziano - The reason Eric said V3 had both of these settings is because you were citing those settings in your reasoning about why this supposedly works differently in V4. Since both V3 and V4 have those same settings, why wouldn't they both have this same problem?

[tonyanziano]

@v-kydela Maybe you both misunderstood my comment.

I only mention the "Bypass ngrok for local addresses" setting:

In both V3 and V4 of the Emulator, we have the option to bypass ngrok for bots running on localhost.

I then go on to say that these options yield different behavior because of how V3 and V4 work under the hood in regards to providing a service url (the entry point into the Emulator REST server):

In V3, we always have a running ngrok URL that we use as the postback URL, so that when the token server grants us a token, it sends it to this ngrok URL (the Emulator) that the Emulator then sends to the bot, completing the auth flow.

This ngrok URL in V3 is accessible at all times, regardless of the "Bypass ngrok for local addresses" setting, and so it is used in the OAuth flow as the postback url.

However, in V4, when we have "Bypass ngrok for localhost" enabled, we instead send the actual Emulator localhost service url as the postback URL, which the token server tries to contact, but cannot, because there is no tunnel from the user's machine to the token server.

In V4, due to some changes and overhauls of the underlying ngrok logic that were not present in V3, when it comes time to generate the postback url for the OAuth flow, the "Bypass ngrok for local addresses" setting is honored. This means that there is no instance of ngrok running, and no way for the token service to deliver the token to the Emulator.

Regardless of if they both have the "Bypass ngrok for localhost" setting, this is why you see the problem only in V4 and not in V3, because the underlying ngrok logic has changed.

[tonyanziano]

@JonathanFingold A fix has been merged into master and should be available tonight at 10 PM PST in the nightly build, and also in the upcoming 4.5 release.

Please feel free to validate the fix in the nightly. :)

[mdrichardson]

I'm still able to repro this with sample 24. With "Bypass ngrok for local addresses" unchecked, it works, and the sample's TokenResponse.Token is the appropriate ewasdhgi9wh4wiu..... However, when checked, TokenResponse.Token is <someGUID>|livechat

[tonyanziano]

That was the sample I used to verify the fix initially, so I'll take a look.

[mdrichardson]

@tonyanziano I experienced this will all auth samples in both SDKs. Not sure if it changes based on whether or not "use a sign-in verification code" is checked (it was for me).

I was also running things through an Azure Service Bus Relay instead of ngrok, if that matters.

Edit: Sorry...this may not have been the best issue to re-open since the issue is the returned token and not the magic code. Still, the "bypass ngrok" option seems to make the difference.

[tonyanziano]

@mdrichardson I'm not able to reproduce the issue you are facing.

I did a clean clone / pull of the samples repo, and set up sample 24 and ran it, and was able to get a valid token with the following configurations:

• bypass ngrok (checked) & not using magic code
• bypass ngrok (checked) & using magic code
• bypass ngrok (unchecked) & not using magic code
• bypass ngrok (unchecked) & using magic code

===

Was this with both C# & Node?

And how exactly were you using Azure Service Bus Relay?

[mdrichardson]

@tonyanziano Hmmm...I'm not able to repro this again. No idea why. But at the time I re-opened this, I was able to repro in Node and C# across multiple auth samples. I'll go ahead and close this and just keep an eye on it in the future.

[textminer]

Hi, I have just open a new one at:
#1756
which I believe might be related.

Thanks