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
Related
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!
I am trying to use the BOT simulator to connect and test my Bot SDK application that I've deployed to Azure App Service.
When I run the bot web api propject locally, I can test it with the simulator no problem.
However, when I try to test the same application that is hosted remoely, the simulator fails. After investigation, I found that the simulator needs ngork to be able to connect to bot service that are hosted remotely
https://github.com/Microsoft/BotFramework-Emulator/wiki/Getting-Started#connecting-to-bots-hosted-remotely
If your bot is hosted remotely, ensure that ngrok tunneling software
is installed and configured. The Bot Framework Emulator is tightly
integrated with ngrok and can launch it for you when needed.
The matter has confused others and they asked questions here:
https://github.com/Microsoft/BotFramework-Emulator/wiki/Getting-Started#connect-to-a-bot-hosted-remotely
Why the simultor has dependance on ngork to connect to remotely hosted bots? It seem conter intuitive since the dns name is publicly available
When you're running the emulator locally and debugging in the cloud, you need to be set up for traffic to flow bi-directionally. By default without NGROK you can post to your bot, but for it to POST back to your client, it needs an IP address to post to. NGROK provides that without you having to set up local ports, etc.
Good morning everyone,
My apologies if this post is too similar to this post:
Dynamics 365 and Azure integration
but I am struggling to understand exactly what is needed in order to setup a web service on an Azure server that is consumable by a Dynamics 365 plugin. Based on my research it appears that it goes as follows but I would like to see if any knows of a better guide.
1.) Construct the web service as normal on the Azure Windows Server.
2.) Register a proper DNS Domain name (friendly-name) and route it to the Azure server.
3.) Secure that Azure server/URL with a certificate.
4.) Call the web service from my C# Dynamics 365 plugin.
Is that everything or might I be missing something critical? Thank you!
4 might be an issue, given you want to use certificate based security, not sure that will work, you might need to use another mechanism, e.g. basic user name and password. Otherwise looks okay.
Plug-in isolation, trusts, and statistics
Web access
Sandboxed plug-ins and custom workflow activities can access the
network through the HTTP and HTTPS protocols. This capability provides
support for accessing popular web resources like social sites, news
feeds, web services, and more. The following web access restrictions
apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving
those credentials.
GET, PUT, DELETE request work fine, but everytime i make a POST request I get an 500 status code. I have no idea where to start debuggin or what to look for. My api is depolyed on Microsoft Azure.
Any tips on what to look for or how to solve this issue would be much appriciated. I know a 500 status code, could be pretty much anything, but i find it really wierd that POST is the only request that dosn't work.
I have no idea where to start debuggin or what to look for. My api is depolyed on Microsoft Azure.
Please make sure your API application could run fine locally before you deploy it to Azure. Besides, http 500 error indicates the server encountered an unexpected condition, if you deploy your app to Azure app service, you could remote debugging web apps to troubleshoot the issue. If you publish it as cloud service Web role, you could try to use Azure compute emulator to debug your cloud service on a local machine.
We're getting ready to rewrite an old native windows mobile application that accesses data through a VPN. We'd like the new version (.NET Windows 10 mobile application) to access data through web services that are protected by Okta. What is the best way to do this?
Thanks!
The best way to do this depends on how the web services are protected.
The main thing to keep in mind is that you don't want to store any secrets on the mobile application.
In an ideal world, these web services would be secured with something like OpenID Connect (OIDC), allowing you to authenticate against Okta (the "IDP") to get access to the web services (the "Relying Parties").
However, the real world is messy, where some web services are protected via SAML, OIDC, OAuth, custom headers, etc.
Without knowing more about your setup, my recommendation would be to build against OIDC, using a proxy server (or "API Gateway") as needed to secure your web services using OIDC.
One of my co-workers at Okta has written a sample iOS application in Xamarin that implements OIDC, I suggest taking a look at the ViewController.cs file in that repository.