I've been following Microsoft's Teams C# tutorials found here, and have been successful for the most part. However, I cannot seem to get my app to work when I host the messaging endpoint myself rather than via their Azure service, which is not an option for me ultimately as the pricing is outrageous for what we need it to do.
I'm hosting the endpoint myself by publishing the sample project and ensuring it's externally available via HTTPS. I can access a custom tab within Teams, so I know that it's online, it's just the messaging endpoint that seems to fail with an "unable to reach app" error when I try and use the messaging extension via a chat window.
When debugging using dev tools, I get 502 error: Bot returned unsuccessful status code Forbidden, error code 1008. Every potential solution I've seen for similar issues hasn't worked for me thus far, though I still feel like it's something incredibly obvious. Are there special steps that need taking when hosting the endpoint yourself? The docs do a very lousy job of explaining the process, probably because Microsoft want you to pay to host the app on Azure.
This is usually caused by the app id / app key not being registered or used correctly in your app, so it's not authenticating to the bot framework service properly. Where/how you do that depends a bit on what sample code / project template you started with, but it's usually somewhere in a .config file (or previously in a .bot file).
The information that you need will be in:
App Id: The Bot Settings page in Azure
App Key: from the Bot settings page, where you got the AppId above, it links to the App registration itself - within there you'll find the section on keys, and you can create a new key (if you've lost the original one)
I know it's generally an error when AppID validation fails. The bot app requests Azure AD to verify the identity.Could your web server access to Azure AD? If you deny to access to outbound with firewall, you should allow Azure IP range.
Turns out it was purely a network issue, that as of yet we still haven't actually figured out. But we tried hosting the app elsewhere and it was fine. That's my recommendation if anyone else has the same problem!
Related
I am working on MS Teams development. I installed the MS Teams toolkit in VS Code, set up my subscription with Azure and sideloading is active in my tenant.
When I run the app, it tries to install ngrok. This step fails as my organization does not allow running ngrok or other words tunnelling from our company laptop. We can run this on a VM to go around this but VM is not always available.
I am looking for a resolution for below scenarios:
Is there a way to debug MS Teams application without ngrok?
If we need a https URL, is it possible to configure a web app to facilitate that?
I tried removing install ngrok step from: /.vscode/tasks.json, but there are subsequent steps it the file dependent on that
I've done quite a bit of research on this question myself as I'd been getting a lot of pushback from our IT department regarding the security threats that come with using a tunneling service like ngrok. It eventually led me to this video posted on the MS forums from a Microsoft engineer who explains it clearly.
What it comes down to is that the Teams client (browser/desktop) approaches webservices (configured in the manifest file) differently depending on the type of interaction. If you're testing configurable tabs, task modules or configuration pages, then you can easily route the app to those sites running on your localhost through the manifest. The Teams client will approach them directly. Problems start to arise when you want to debug what happens when you use a bot or message extension, outgoing webhook or MS Graph change notifications (just quoting the video here, there might be other scenarios).
Basically, what happens is that the Teams client goes through a Microsoft-hosted service first, called Microsoft Teams Services, which will then approach your bot framework cloud service (typically an Azure Bot resource). This then forwards any incoming messages to whatever endpoint you have configured. What happens in these separate stages isn't completely clear to me, but what I do know is that whatever is typed by the user in the Teams client is translated to a JSON structure that can be interpreted by your server-side bot code (for C# apps, this is typically your CloudAdapter-derived class working with your TeamsBot-derived class). These messages are then routed to the relevant TeamsBot class method based on properties in the JSON.
Now the issue that ngrok solves is that, when the Teams client goes onto the public internet to reach the MS Teams Services server and then the Azure Bot resource, it then needs a public address to route the traffic to. It doesn't know about your local network anymore. As ngrok sets up a TCP tunnel between their server and your local PC, it is able to route traffic coming to their server to your PC. The Azure Bot now has a public address to send the messages to.
To my knowledge, there is no way to circumvent this as long as Teams client inner workings always make it go outside of your local network. For chat scenarios, the Bot Framework Emulator might offer a solution for unit testing. As far as I can see it performs the translation of chat input to the JSON message model of the Bot Framework and routes it to a local address for your chatbot to process it. Unfortunately, this doesn't work for chat message extension type messages.
As for the question whether ngrok can be avoided, I think the answer is definitely yes but you would need an alternative. There's several alternatives around that you might be able to host yourself if you have the technical know-how. Depending on your IT department, being in control of the public-internet-facing server might be a more viable solution for them. Another option is to host ngrok on a VM or cloud machine with less access to your internal network's resources than your PC/laptop has and test the code there.
TL;DR: If the the feature you're testing is approached directly by the Teams client, you can enter localhost in the manifest and debug it. If you're testing a feature that the teams client approaches through Microsoft Teams Services and the Bot Framework, you need to find a way to expose your code to the public internet. You can use ngrok or host your own alternative depending on requirements.
use mkcert to generate a certificate for ex. localhost.test
add losthost.test to your host file
use https://localhost.test for debugging
I am working on adding support for our cloud storage solution to MS Teams but there is no central server you can send http messages to and get meaningful relies back from. I have no experience with creating Teams apps so I was hoping someone with Teams apps experience could tell me if this is even possible. At this point I only need my app to work on Windows and OS X.
This is how I would like my Teams App to work:
Each member of the team already has our cloud storage app running locally on their machine which provides access to the files.
Within MS Teams the user adds a file reference to a message via a message extension that would result in a link unfurl creating a card that contains an 'Open' button. The URL in the card would be one generated by our locally running cloud storage app. Other members of the team could then open this file by clicking the 'Open' button. The action of the open button would be to send the URL to our cloud storage app that would then open the local copy of the file on that team members machine.
Is it possible to do something like this within a Teams app? The communication between the Teams app and our cloud storage app would be done over our own protocol.
If it weren't for the fact that all bot communication must be done over https rather than http the local cloud storage app could act as the server.
All the communication in Teams with 3P apps needs to happen over https public endpoint. You could use ngrok to tunnel to local.
I want to develop a product which simplifies the way of creating conversational chat bots using Microsoft BotFramework SDK. As we can build and host web application on-premise completely.
So can we build the similar thing using bot framework on a self hosted environment?
Here is the link for Microsoft Bot Framework: https://dev.botframework.com/
You can, indeed, build a bot entirely on-premises/self-hosted, provided that you don't need to connect to a Channel like Teams.
Background
Basically, bots communicate via:
User interaction with DirectLine Client (like Web Chat) ->
DirectLine API receives data and sends to bot ->
Bot hosted anywhere receives message
Note:
WebChat is just a DirectLine client. If you want to build your own WebChat, you can clone the repo and build it yourself. However, that all this does is make it so you can host your own webchat.js file, if you really want to be self-hosted.
Steps
With that in mind, all you need is:
A Direct Line client like Web Chat (specify domain property with your own endpoint when you call createDirectLine), or you can write your own client
You own DirectLine API implementation like offline-directline (more info)
Host your bot somewhere
Security
With this approach, you won't be able to use the typical appId/password setup.
You can manually implement our security protocol by following this document
Even though it is possible to manually implement the security protocol, we recommend reusing our existing open-source libraries
Based on answers, putting a more complete answer here. Since the option exists to have internet connectivity, I'd definitely suggest creating the solution as a "regular" Bot Framework bot, using the Azure Bot registration. Importantly, there are TWO options to do this - the most obvious one creates a "registration" for the bot but ALSO defaults to hosting it in an Azure Web App, which has a cost associated that can be quite significant. HOWEVER, there's another option, to create just a "Bot Channel" registration, which means you get a bot registered in Azure, but not necessarily hosted in Azure.
I've described this more in this post and you want to use the "Bot Channels Registration" in Azure, not the "Web App Bot". Then, on the "settings" screen you can define what the bot's actual address is (see here for a view of the Settings screen).
So, overall that should help - basically the bot just needs to have an HTTPS, internet-accessible endpoint. HOWEVER, that said, it's possible to host your bots inside Azure Functions, rather than Azure Web Apps, and the cost is dramatically cheaper (cents vs dollars, especially with low traffic). It's a bit of work, especially as the default samples default to the more standard options, but it works quite well.
I've recently launched a new blog, by the way, and I've got a post describing some of what I've learned so far about how bots work, that would be good to know as part of this. See How Bot Calls Actually Work.
We're in the process of migrating from an entirely on-premise solution with our own DirectLine server to Azure Bot Channels Registration because of the requirement for MS Teams integration.
I have been trying to make my application verified for quite some time already. The main problem that I have is that my homepage and other pages(except web hooks for push-notifications and oauth2 flow) are private (because it's dev environment, not prod) and if you try to access them from the Internet, firewall will not allow you doing so.
Considering what I wrote above, I posted OAuth Developer Verification Form with the links to my app that aren't accessible for the external network. Now I got the following message from Google:
Dear Developer,
Thank you for your patience. Please reply back with a test account email and password, so we can experience the user sign-up flow, validate the app services and then proceed with OAuth Verification process.
Please do not hesitate to reach out to us if you have questions or concerns.
Even if I provide the account in my application, Google will not be able to reach the application.
I am sure that there are thousands of applications that have DEV/QA and other environments that aren't accessible from the Internet.
How do you go through verification process?
How do you go through the process in general?
What URLs do you specify in the form? Are they private?
How do you provide user for the Google if you application is not available through the Internet(only web-hooks are available)?
This was so easy for PROD environment, but appears a real nightmare for DEV environments.
Thank you!
I'm new to azure mobile services development and any help will be greatly appreciated.
I have created sample mobile service application and could successfully launch and debug it locally. As a next step I've added google authentication. Everything works fine when the service is Published and running in the cloud. But, I could not make the service to run locally so that I can debug the service for cases when the user is authenticated.
So for I have wrestled with IIS Express and made it work with HTTPS on port 44300. But Google authentication services complained because of redirect URLs mismatch, even though I've added https://localhost:44300/signin-google to redirect list.
I feel like I'm not doing something correct here. Something does not make me believe that debugging locally is not possible.
Thanks,
Ruben
Is possible to debug in localhost, but the google/facebook/Microsoft authentication should not be tested, because it is provided out-of-the-box by Azure Mobile Service team.
you should configure it in Azure Portal and then you should implement it in your application like documentation provides.
The following resources has the references to the Authentication articles:
Azure Mobile Services for Client Apps