fix

docs/security/safe-storage-app-secrets.rst

@@ -3,7 +3,7 @@ Safe Storage of Application Secrets
 
 By `Rick Anderson`_ and `Eilon Lipton`_
 
-This tutorial shows how your application can securely store and access secrets in the local development environment. The most important point is you should never store passwords or other sensitive data in source code, and you shouldn't use production secrets in development and test mode. The secrets manager tool was written to help prevent sensitive data from being checked into source code.
+This tutorial shows how your application can securely store and access secrets in the local development environment. The most important point is you should never store passwords or other sensitive data in source code, and you shouldn't use production secrets in development and test mode. The secrets manager tool was written to help prevent sensitive data from being checked into source code. The :doc:`../fundamentals/configuration` system that is used by default in DNX based apps can read secrets stored with the secrets manager tool described in this article.
 
 In this article:
     - `Environment variables`_
@@ -14,7 +14,7 @@ In this article:
 Environment variables
 ^^^^^^^^^^^^^^^^^^^^^
 
-Your `Startup`` class should call `AddEnvironmentVariables` as the last configuration method so when 
+Your ``Startup`` class should call `AddEnvironmentVariables` as the last configuration method so when 
 `DNX <http://docs.asp.net/en/latest/dnx/overview.html>`_ reads environment variables, and a key is found in a configuration file and the environment, the environment value takes precedence over the configuration file. (See :doc:`../fundamentals/configuration`.) For example, if you create a new ASP.NET web site app with individual user accounts, it will add a default connection string to the *config.json* file. The ``Data:DefaultConnection:ConnectionString`` key value in the *config.json* file uses LocalDB, which runs in user mode and doesn't require a password. When you deploy your application to a test or production server, you can override the ``Data:DefaultConnection:ConnectionString`` key value with an environment setting that connects to a test or production SQL Server. That key value would also contain a password to connect to the SQL Server.
 
 Apps frequently require passwords, such as a client ID for OAuth. These passwords and other sensitive data should never be added to *config* files inside your projects source tree, as configuration files can be accidentally checked into source code. The secrets manager tool provides a  mechanism to store sensitive data for development work outside your project tree. The secrets manager tool is a DNX console application that is used to store secrets used by ASP.NET applications in the development environment.
@@ -105,7 +105,7 @@ How the secrets manager tool works
 
 The tool operates on project specific configuration settings that are stored in your user account. In the example above, the command window was opened in the project folder (containing the file *project.json*). You can run the secrets manager tool from other directories, but you must use the ``-project`` switch and pass in the path to the *project.json* file.
 
-The secrets manager tool abstracts away the implementation details, such as where and how the values are stored. You can use the tool without knowing these implementation details. In the current version, the values are stored in a `JSON <http://json.org/>`_ configuration file in the user profile directory:
+The secrets manager tool abstracts away the implementation details, such as where and how the values are stored. You can use the tool without knowing these implementation details. In the current version, the values are stored in a `JSON <http://json.org/>`_ configuration file in the user profile director:
 
 - Windows: ``%APPDATA%\microsoft\UserSecrets\<applicationId>\secrets.json``
 - Linux: ``~/.microsoft/usersecrets/<applicationId>\secrets.json``