As of Parse's announcement of Cloud Code Webhooks, I've build my own server environment instead of using Parse Cloud Code.
I'm running my server locally, changing the Parse webhook to point at my ngrok tunnel, as described here.
This all works great, but one problem arises when more people from my team, has to work on the server, on the same time. Since the webhook to Parse only can (AFAIK) point to one single webhook URL, we can only have one server running, pointing to its localhost address, through ngrok.
Is anyway to create a workaround for this problem?
Feel free to ask my elaborate on any of my points.
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've setup a functional Cloudflare Worker via its route and domain and am using the Worker playground and the quick editor to avoid a deployment.
However, when developing locally I cannot make a request to the worker and get a CORs error.
I’ve read all the docs and implemented most CF security features within Zero Trust. However, nothing is getting us access to our deployed Worker due to strict CORs rules. (which we want)
On my machine I am routing through WARP and it is configured for my
team name.
I have installed and configured a root access certificate, perhaps
not applicable to this issue.
I have also tried to manually auth by visiting the worker URL and
getting a login code emailed to me. Perhaps CF Access is not related
to Workers?
We need clarification because the docs do not clearly explain the flow for access to Worker URLs when working on localhost.
Community question here.
How do we develop apps with Workers and strict CORs by authenticating a computer or user?
I think you can use Transform Rules for set/remove/update CORS.
It should work for you, because according to traffic sequence diagram header modifications performs before workers.
I've gone over the intro amazon gamelift tutorial, and something I'm trying to understand is how a web app transitions from communicating with the app backend to a gamelift instance.
For example the following call can tell the backend that an available session exists, and returns a list of IP addresses (as well as other information.) Is it a matter of returning that desired IP to the client, and transitioning to a websocket connection with that IP, or are there more authentication details I'm completely missing, etc.?
It looks like the client side SDK for this is still only available in C#:
https://forums.awsgametech.com/t/javascript-as-a-game-client-for-a-gamelift-server/7679/6
If I end up porting this to JS, I'll edit this comment to point to a public repository.
I am trying to debug a bot which is running locally, and when i use the ngrok url on bot emulator it is returning the following error "The bot is remote, but the service URL is localhost. Without tunneling software you will not receive replies".
Any help please?
thank you.
If you are running locally you do not need to use ngrok. You just need a single .bot file with the endpoint URL http://localhost:3978/api/messages. You should not enter the App ID and Password since you are running locally (your bot won't connect otherwise, and may be why you are seeing that message). I use this single .bot file for every bot I test locally, the only reason you would need to change is if you're listening on different ports for some reason.
To test:
Start the bot via node with node index.js. If you are using the MS templates and haven't changed any settings, you'll see a message that the bot is not listening on port 3978.
Open your .bot file in the emulator with the http://localhost:3978/api/messages endpoint
Bot should connect and you can begin testing!
Note that if you are testing behind a corporate firewall and you are using services like LUIS, QnA Maker, etc., those calls will likely be blocked and the bot will error out. You do not need ngrok to fix this! The easiest way is to set your proxy via HTTPS_PROXY in your .env file (you can define it in your code too via process.env.HTTPS_PROXY but I don't recommend that since you don't want that setting in production).
Do not also set HTTP_PROXY, I'm not entirely sure why but this will prevent your bot from working.
Note that some of the native botframework connectors, like CosmosDB, don't respect the .env HTTPS_PROXY variable and those calls will fail. If you are making those API calls directly, you shouldn't have any issues.
I have a server of my own running locally on my wifi, on 0.0.0.0:5000.
I have built an app with the parse.com backend, and I want to link this server to Cloud Code, so I can call functions on it.
I am completely lost and don't know where to start to bring my server online with only Parse being able to access it and use its API.
Or am I better off renting a VPS and connecting to that?