With most Azure services I can run an emulator on my local machine, for example the storage emulator. This allows me to store the credentials to my real azure storage account as an app setting on my azure web site. And locally I have the credentials to the emulator in my web.config.
But how to achieve the same kind of security with Azure DocumentDB? I would prefer not to store the credentials in my local web.config, but at the same time I need to be able to run the application locally when developing. As I understand there is no emulator for the DocumentDB? And the endpoint and auth key is the same for all DocumentDB's I create?
So, to sum up my question, what is the best practice to handle the auth key / end point when developing and using Azure DocumentDB?
You are doing the right thing by storing your connection strings in your Azure Website environment so they are not in your web.config and therefore not in your source control system. And your local development process works well for you only because you are using the emulator which doesn't require any credentials. That is not always going to be the case though as you pointed out with Document DB and potentially with other resources you may be using to store data.
The guidance for storing and deploying app settings and connection strings is to keep those in separate config files locally that are never checked into your source control system. Then, in your web.config file, reference these files. This keeps the confidential information out of your web.config.
For example, for connection strings it would be something like this:
<connectionStrings configSource="ConnectionStrings.config">
</connectionStrings>
For app settings it would be something like this:
<appSettings file="..\..\AppSettingsSecrets.config">
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
...
</appSettings>
More information on this technique is available here.
Another alternative is to store the key as an environment variable and get your code to read it.
On another note, your development environment should have a separate docdb, one that is not your production environment. Since docdb does not offer an emulator and no free-tier, this leads to higher costs for development.
Related
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.
Is it possible to a custom configuration section inside of an Azure Cloud Service Configuration, the same way you would in a regular ASP.NET website?
I.e in a regular ASP.NET site your Web.Config would have something like this:
<configuration>
<configSections>
<section name="myCustomConfig" type="MyNamespace.MyType" />
</configSections>
<myCustomConfig someProperty="someValue" />
</configuration>
How is this done in Cloud Services and shared across multiple different roles?
At this time I do not believe this is possible. There is a post for it on user voice you can vote up: http://www.mygreatwindowsazureidea.com/forums/169386-cloud-services-web-and-worker-role-/suggestions/459944-enable-custom-configuration-sections-in-csdef-cscf.
As a way around this you could put configuration into a file that is stored in BLOB storage. On start up, or when it is needed, all instances could then go pull the file to get the configuration. To deal with changes to the configuration you could either have the instances pulling the configuration from time to time as a refresher, or you could tap into the environment changed event in RoleEntryPoint that is used to detect changes to the Service Configuration. Add a setting to the service configuration that is a version number of your shared config file or something, just anything that could be modified to trigger the RoleEnvironment.Changing event.
I have created a Cloud project on VS 2012 with .net 4.5. This consists of two web roles, an API and an front end website.
I have followed the instructions here: http://msdn.microsoft.com/en-gb/library/windowsazure/gg443832.aspx in order to set up remote desktop, and deployed the service.
When I try to connect (I have double and triple checked the credentials), I get told that 'The credentials that were used to connect to did not work. Please enter new credentials.
My web roles are both operational, and I can visit them both in the browser.
I have tried waiting a while after deploying for changes to propagate, but this makes no difference. The only thing I can think of is that I have not done anything with certificates as of yet other than download the appropriate bits in order to deploy from visual studio. I can't find any documentation that says I need to though.
I have also tried out adding various domains to the username but nothing works.
Am I missing something, or is there a chance that there is a bug with azure at the moment?
EDIT: Have now tried deleting the cloud project from visual studio, deleting the cloud service in azure and redeploying with only a single web role. Still seeing the problem.
Just checking for completeness,
Did you use the button on the website for your first access?
http://blogs.msdn.com/b/avkashchauhan/archive/2011/04/03/how-to-login-into-windows-azure-virtual-machine-using-remote-desktop.aspx
On the other hand, this is the link that worked for us, it includes how to set up the cert needed too.
http://geekswithblogs.net/MagnusKarlsson/archive/2012/12/03/connect-to-running-web-role-from-remote-desktop-connection-and.aspx
I fixed this by removing the <Import moduleName="RemoteAccess" /> and <Import moduleName="RemoteForwarder" /> lines from the .csdef then removing all references to Microsoft.WindowsAzure.Plugins.RemoteAccess and Microsoft.WindowsAzure.Plugins.RemoteForwarder within the .cscfg files. I then was able to deploy and enable remote desktop access from the newer Azure portal.
After adding users to the Azure Active Directory Domain, (e.g. smith#mydomain.onmicorosft.com), I tried logging in as one of those users, but got "Your credentials did not work." After some trial and error, I found that I had to add the users (e.g. smith) as local users on the VMs. Once I did that, and assigned, passwords, the users could RDP in.
I would like to deploy my MVC3 app to Azure using multiple physical sites of the same app.
It's great that I can use the sites element in ServiceDefinition.csdef to do this.
But I want each of the sites to connect to a different database. The connection string is in the web.config. Is there an easy way to do this, besides logging into the vm and changing it by hand?
You could register a startup task to go and modify/move the web.config files when the VM starts up. It's a bit messy, but cleaner than doing it by hand!
http://msdn.microsoft.com/en-us/library/windowsazure/gg456327.aspx
[Answer to your comment] - With Windows Azure (actually with any PaaS solution) The first rule of thumb is that when the role starts all the configuration should be ready and the second rule of thumbs is that nothing should be done in VM through RDP access, because changes will not persist. Due to this required configuration either deployed in Azure Package or modified directly from start up task.
[Answer to your question]
In Windows Azure you can run multiple sites within one Web Role however they all should share the same main web.config because multiple sites are running within one Web Role. Here is how you can do it:
http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx
Now as your requirement is to have multiple databases, so in your web.config you can add multiple database connection string as below:
$
<ConnectionString>
<Add name="DB1" connectionString="Data Source=DS1.........."/>
<Add name="DB2" connectionString="Data Source=DS2.........."/>
</ConnectionString>
once you have above, in your ASP.NET code you can enumerate these connection strings and use with specific sites as described in the given example:
http://www.dotnetspark.com/kb/780-how-to-use-multiple-database-connection.aspx
Finally, you can add multiple sites with your web role during development and can also have specific DB connection specified in web.config so I dont think there is any need to use startup task at all or do something in VM, unless i am missing something here.
I'm in the process of deploying some windows azure projects and I've noticed that it's a bit of a pain to constantly switch my role configuration settings from using LocalStorage to actually use my Windows Azure Storage connection strings.
For local development, I want to use this:
UseDevelopmentStorage=true
But for deployed apps, I want to use something like:
DefaultEndpointsProtocol=https;AccountName=myAccountName;AccountKey=blah
I end up either changing my role's configuration connection strings just before I deploy, or if I forget to do that, I'll attempt to go into the Windows Azure portal and change them (but that usually happens after I watch my role instances start and stop over and over).
I feel like I'm missing something basic, but is there a straight-forward way to have the deployment process switch my role connection settings to use the production storage accounts instead of local storage?
You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager
This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config
For example
CloudConfigurationManager.GetSetting("StorageConnectionString")
Will look in the appropriate cscfg file for StorageConnectionString setting, then it will search the web.config and then app.config.
If you want to use Visual Studio config transformations, see my answer to the question Panagiotis mentioned.
Switching from one connectionstring to another when moving from development to cloud
Cheers.
If you use CI server you can change the connection string there automatically. Details here.
I've answered a similar question here:
Visual Studio 2010 can apply Debug or Release transformations to Web.config, but what about the Azure settings?