有关Azure DocumentDB身份验证密钥的最佳做法？

Question

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?

Answer 1

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 .

Answer 2

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.