I've just setup a new Azure Mobile App (first time using one since the old Mobile Services).
After setting up the app you can use one of the "Quick Start" offerings to create a Xamarin.Forms app that connects to your service and they create a dummy ToDoItem table for you. Then you can download the source for the app which is helpful.
The bit where I'm left scratching my head is that previously with the Mobile Services you would have your Mobile Services URL and an API key that was to stay secret (how secret you can keep this is open to debate as at the end of the day it's in your code and is probably possible for someone to reverse engineer the APK or whatever and get it)... BUT with the new Mobile App service there doesn't seem to be any notion of this secret API key. I've hunted around the sample app source and can only find the URL for the app service and nothing else.
So my question is, what's to stop someone else using my Mobile App service URL and reading/writing to (or worse, deleting from) my SQL Server tables?
Perhaps I'm missing something... If anyone can shed any light on the subject that would be great.
The application key was dropped as a security mechanism as it gave a false sense of security. As you mention, there is nothing to stop people from obtaining the key through reverse engineering the app or capturing network traffic - in some ways it is worse than no security at all!
We highly recommend you set up your tables to only allow authenticated access. Using the social media identity providers don't give you any role based access control, but with Azure Active Directory, you can set up groups fairly easily.
You can find some basic information and tutorials (Xamarin.Forms is included) at https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-auth/. There is also a wealth of information on Mobile Apps in general at https://shellmonger.com/30-days-of-azure-mobile-apps-the-table-of-contents/.
Related
I am developing a chatbot on Microsoft teams for internal use only, which needs to be deployed and hosted on the intranet. In order to NOT make the bot's APIs public I plan to use Azure VNET. Within this VNET how can I connect the azure bot service resource?
Could someone please guide me on how to set this up? Also, direct me to any concepts that I need to understand, to tackle this problem.
I can't advise on the VNET side of things (hopefully the Microsoft Bot engineers here on the site can advise), but here some other things that might be of use/interest in securing your bot for on premises/internal company use:
Of course you'll side-load this app into the private company store, not the real Teams app store - do you need any info on how to do this?
I'd strongly suggest blocking access to your bot from tenant(s) other than your own - Microsoft have a sample middleware to do just this, but as per this link it's now been rolled into the core Bot Framework SDK. This means that even if someone from another tenant (i.e. company) tried to access your bot, it would reject their messages.
There are also mechanisms to sign users in, like using a signin card that could be applicable here, but I'm not sure you can lock users to a specific tenant this way. This would definitely be useful though if your bot is accessing any outside resources though, as it could be used to lock access to those.
Probably (2) above is your easiest and best bet, and it's pretty easy to implement.
I am responsible for a web application that we sell to customers all around the world, this application is a web application that I have been tasked with including functionality to surface O365 content within, this has lead me to the MS Graph API which I am currently implementing as a proof of concept.
At the moment I have everything working within my dev environment with localhost and dev URIs listed as application redirect URIs under the AD application, however, in the real world there could be an unlimited amount of URIs that our customers are using, meaning that as I currently understand it will mean that I am going to have to either:
1) Get them to create an application within their own AD organisations or
2) Manage the URIs within in our app here locally.
Now the question I have is, what is the best approach I can take here?
Is there a secret option 3 that I have not been able to dig out from the Microsoft documentation or the internet yet?
Thank you for any help or advice you can provide.
I am using Azure Web Apps to host my website. The website is loaded from a native apps for iOS and Android. During normal days non peak time , the web is operating as expected. However, from time to time , we are going to push out notification via apns or google gcm and that will drive users back to the apps. From there, content will be loaded from the website which is hosted from the Azure Web Apps.
During this peak times where there are thousands of requests coming in, there will be very high degree of fallout which results in errors.
It is shown in the picture below .
Traffic of the web apps after the push notification blasts
I have make sure that the database will not have any bottleneck during the operation. We are using SQL from Azure as well.
From the new portal, we are using service tier 'S1' for the App Services.
Previously, when the apps are developed, Web Apps and Mobile Services are separate service which are now join to become App Services.
Is there anything I could adjust from the azure backend or there is something which I missed out to handle ? Currently , we are also making the instance to be auto scaling.
As in conclusion, during high concurrent requests rushing in, the web apps seems to stop responding.
I would propose to implement the retry logic if there is no such yet and troubleshoot using the different modes.
UPD:
There is a detailed "analyzing performance" official guidance here - https://azure.microsoft.com/en-us/documentation/articles/app-service-web-troubleshoot-performance-degradation/ .
The most simple way to understand (or just mitigate) if the issue if somehow related to the underlying backend (throttling etc) is to change the mode site is working in. In your case, it can be S or even P.
Next step, if we eliminate the possibility of the throttling/etc, is to implement the diagnostics. My favourite tool is Application Insights, there is New Relic and other great tools as well. There are good guidances i saw and used:
http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/monitoring-and-telemetry
https://github.com/mspnp/performance-optimization/blob/master/Assessing-System-Performance-Against-KPI.md#insertlink#
So, there is not silver answer about your question - highload is highload :-) Without access to the sources and website, and load tests results it is difficult to say what component of the project behaves itself bad.
If that is the helpful answer, please mark it as a helpful or as the answer. Thanks!
Can anyone please point out any benefits of using Azure Mobile services vs using a plain Azure app service / clean web api? For a starter / project type for a backend mobile solution.
I have somewhat mixed feelings on why I would want to use Azure Mobile Services.
As far as I see on Azure Mobile services you have an easier way of authenticating, you can use the notifcations hub more easily
and you have the different "built-in" ways of handling data (table storage etc).
Usually you would want some custom logics, user registration and handling when users register to your backend and you would like a more solid way of handling
and storing the data not privided by the OOTB datastorage.
You might also have another preference than using the /Table/ odata-endpoint you get with it or end up doing lots of logics to make your DAO's return data in properly for the OData endpoints.
All these things; IMO makes it more difficult to make the API/backend clean when using Azure Mobile services rather than a simple Web API with OData endpoints and swagger documentet API that can be used in a mobile-app just as easy.
Implementing / handling authentication and notifications ++ in Web Api ain't that diffucult nor time consuming.
So my problem Azure Mobile services is that it tends to fine for dev / prototyping and testing, but it might get really messy really fast when developing a proper backend.
Any thoughts and reasons why one should choose one instead of the other?
Think of Azure Mobile Services as V1 and App Service/Mobile App as V2. While Microsoft hasn't announced that Mobile Services will be phased out in the near future, if you start a new project, you should definitively look at App Service.
due to the fact that many people are confused about wether to take Web API or Web App or something different. They are going to put it all under one name. The underlying technology will be the same "i think".
But now you'll have in your portal the opportunity to add mobile push notifications, or add your swagger api definitions.
So when you're goint to stick with App Services you're not going to limit yourself.
Even when you're going to take Web Api you'll get all the functions as if you would take an App Service (if i'm correct).
*Edit: I looked it up in the portal. As I said, my old Web App Projects have the same settings as Web Api projects. So you don't need to decide anymore which kind of project you're taking. You get all the benefits out of the App Service.
I am currently doing some research for the development of a mobile application for our company that should support offline data sync (on an iPad). We have explored many possibilities including PhoneGap/Cordova, Xamarin and simply native iOS development. Xamarin, for many different reasons, seems to be our best choice, so my question will assume we will develop in Xamarin.
I was looking into a library for managing offline data synchronization and the most obvious solution is Microsoft Azure MobileServices. However, my company is Canadian, and apparently it's hard to trust (legally) our data to clouds based in the US. Since we already deployed internally our WebApi on our intranet, I figured there was probably a way to point the MobileServices library to our own WebApi. I have read about the Azure Hybrid Connection possibility, but our data still conveying through Microsoft servers might not be a possibility. So, my question is this:
Is there a way to configure the Microsoft.WindowsAzure.MobileServices Client library to point directly to our intranet, RESTful WebApi backend, without going through any Microsoft Azure servers ?
I understand that, in order to be able to use the Client librairies seamlessly, we probably would have to adapt our WebApi to implement the necessary .net Backend interfaces. I'm mostly wondering if it's even possible as the MSDN documentation on the libraries all seem to point to direct connections to their servers (no possibilities to configure your own connection strings) and all instructions redirect you to their Azure Mobile Services website.
Thank you.
If you look at the API for your mobile client, you'll notice that the Azure Mobile Services Client SDK only cares about two things:
new AzureMobileClient( url, appkey)
...where it's hosted shouldn't be a concern. Everything else is just configuration.
If you want to host the Azure Mobile Services Backend on your own servers, technically you could do this, but there are likely a few caveats. Microsoft has announced that they will be launching a Canadian Azure data center, but we won't see it until 2016.
In the meantime, here's how you can host the services locally. Note that I have not tried to emulate all of the features of Azure Mobile Services (aka Zumo) so your mileage (or kilometerage) will vary.
Hosting Locally:
From a technical feasibility, you absolutely can run the services locally. I know this because you can create the Azure Mobile Services Backend project from within Visual Studio and run it locally for development purposes. This is what our development team does for testing their mobile applications.
Note that you can create the Azure Mobile Service backend directly from within Visual Studio: New Project -> Cloud -> Azure Mobile Service. You can also download the exact same template (pre-configured with your URL and ApplicationKey) directly from the Azure dashboard: Create -> Mobile Service.
Obviously, if you're hosting it on your server it will be up to you to configure and use a proper SSL certificate for your site.
ZUMO Permissions:
By default, the security roles on the server are turned off. So if you're locking down any of your methods using the [AuthorizeLevel] attribute these settings will be ignored at runtime. If you need to enable this feature you can do so by modifying the WebApiConfig.Register() method and marking the site as self-hosted: config.SetSelfHosted(true).
Configuration:
From a configuration perspective, the Azure Mobile Service dashboard provides several tabs for configuring Identity, Push Notifications, Connection Strings and App Settings. Sadly, you won't have a dashboard, but all of these settings have a corresponding value in the local web.config. Any value you provide here is automatically overwritten in Azure, but they're used when running locally.
The minimum settings you'll need to configure are listed here. The ApplicationKey you can distribute with your ZuMo client, but the MasterKey is for the Admin authorization level so you'll want to keep that secret. The MobileServiceName is used by the EntityFramework for your database schema and what appears in the URL of your site.
<add key="MS_MobileServiceName" value="myzumosite" />
<add key="MS_MasterKey" value="masterkey" />
<add key="MS_ApplicationKey" value="appkey" />
Values that start with a MS_ prefix map to corresponding values in the Azure Portal. MS_GoogleClientID and MS_GoogleClientSecret map to the Google Identity values in the dashboard, for example.
Any other value in the AppSettings node is immediately accessible via the ApiServices.Settings property and corresponds to the Settings node in the Azure dashboard.
Database connection strings continue to exist in the connectionStrings node. The same is true for azure notification hub.
Database:
Obviously, the database you configure will be up to you as well. Permissions and User accounts are also obvious. There may be some minor differences between the SQL Azure syntax for Entity Framework database migration scripts that you'll need to worry about. (I've discovered the database migration scripts don't work from the Package Manager, but they do work when the database scripts are run when your website starts)
Caveats:
You will not have a nice dashboard for monitoring performance of your site, reviewing logs or changing runtime settings
You will not be able to scale out your site immediately; Scaling and deployment will be your problem
Deployment configuration is your responsibility (Project -> Publish won't be available unless you configure it)
Not sure if you'll be able to use Azure Active Directory as an authentication scheme, though from the sounds of it that won't be a concern. You can write your own authentication providers: Microsoft's Zumo library only supports a handful, but the underlying Owin.Security package that Microsoft uses supports several dozen systems!
Your site will need to be publically visible to your mobile clients
Push Notifications should work, but you will be using Azure's notification hub for this.
I have no idea where ApiServices.Log will go
The easiest path to take would be to:
Create the Mobile Service in Azure to get the notification hub and settings preconfigured
Download the starter site from the dashboard
Configure the web.config as mentioned here.
It's not possible to simply configure WAMS Client library to work with your own WebApi Backend.
But WAMS library is available at github, so I'm sure you can reuse a lot of code from the WAMS project, especially if you want to use a PCL project.
To route your data securly through Azure, you could think about setting up express route. Additionally, for last weeks update, it's possible to apply a custom domain to the WAMS Backend, including your own certificate to secure your connection.