Stockage sécurisé des secrets d’application en développement dans ASP.NET Core

Par Rick Anderson et Kirk Larkin

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

Ce document explique comment gérer des données sensibles pour une application ASP.NET Core sur un ordinateur de développement. Ne stockez jamais de mots de passe ou d’autres données sensibles dans le code source. Les secrets de production ne doivent pas être utilisés pour le développement ou le test. Les secrets ne doivent pas être déployés avec l’application. Au lieu de cela, les secrets de production doivent être accessibles via un moyen contrôlé comme les variables d’environnement ou Azure Key Vault. Vous pouvez stocker et protéger les secrets de test et de production Azure avec le fournisseur de configuration Azure Key Vault.

Pour utiliser des secrets utilisateur dans une application console .NET, consultez ce problème GitHub.

Variables d'environnement

Les variables d’environnement sont utilisées pour éviter le stockage des secrets d’application dans du code ou dans des fichiers de configuration locaux. Les variables d’environnement remplacent les valeurs de configuration pour toutes les sources de configuration spécifiées précédemment.

Envisagez une application web ASP.NET Core dans laquelle la sécurité des comptes d’utilisateurs individuels est activée. Une chaîne de connexion à la base de données par défaut est incluse dans le fichier du appsettings.json projet avec la clé DefaultConnection. La chaîne de connexion par défaut est pour LocalDB, qui s’exécute en mode utilisateur et ne nécessite pas de mot de passe. Pendant le déploiement de l’application, la valeur de clé DefaultConnection peut être remplacée par la valeur d’une variable d’environnement. La variable d’environnement peut stocker la chaîne de connexion complète avec des informations d’identification sensibles.

Avertissement

Les variables d’environnement sont généralement stockées dans du texte brut et non chiffré. Si la machine ou le processus est compromis, les variables d’environnement sont accessibles par des parties non approuvées. Des mesures supplémentaires peuvent être nécessaires pour empêcher la divulgation de secrets utilisateur.

Le séparateur : ne fonctionne pas avec les clés hiérarchiques des variables d’environnement sur toutes les plateformes. Le double trait de soulignement __ est :

  • Pris en charge par toutes les plateformes. Par exemple, le séparateur : n’est pas pris en charge par Bash, mais __ est pris en charge.
  • Remplacé automatiquement par :

Gestionnaire de secrets

L’outil Gestionnaire de secrets stocke des données sensibles pendant le développement d’un projet ASP.NET Core. Dans ce contexte, une donnée sensible est un secret d’application. Les secrets d’application sont stockés dans un emplacement distinct de l’arborescence du projet. Les secrets d’application sont associés à un projet spécifique ou partagés entre plusieurs projets. Les secrets d’application ne sont pas archivés dans le contrôle de code source.

Avertissement

L’outil Gestionnaire de secrets ne chiffre pas les secrets stockés et ne doit pas être traité comme un magasin approuvé. C’est à des fins de développement uniquement. Les clés et les valeurs sont stockées dans un JSfichier de configuration ON dans le répertoire du profil utilisateur.

Fonctionnement de l’outil Gestionnaire de secrets

L’outil Gestionnaire de secrets masque les détails de l’implémentation, tels que l’emplacement et la façon dont les valeurs sont stockées. Vous pouvez utiliser l’outil sans connaître ces détails d’implémentation. Les valeurs sont stockées dans un JSfichier ON dans le dossier de profil utilisateur de l’ordinateur local :

Chemin du système de fichiers :

%APPDATA%\Microsoft\UserSecrets\<user_secrets_id>\secrets.json

Dans les chemins de fichier précédents, remplacez par <user_secrets_id> la UserSecretsId valeur spécifiée dans le fichier projet.

N’écrivez pas de code qui dépend de l’emplacement ou du format des données enregistrées avec l’outil Secret Manager. Ces détails d’implémentation peuvent changer. Par exemple, les valeurs secrètes ne sont pas chiffrées, mais pourraient l’être à l’avenir.

Activer le stockage secret

L’outil Gestionnaire de secrets fonctionne sur les paramètres de configuration propres au projet stockés dans votre profil utilisateur.

L’outil Gestionnaire de secrets comprend une init commande. Pour utiliser des secrets utilisateur, exécutez la commande suivante dans le répertoire du projet :

dotnet user-secrets init

La commande précédente ajoute un UserSecretsId élément dans un PropertyGroup fichier projet. Par défaut, le texte interne de UserSecretsId est un GUID. Le texte interne est arbitraire, mais est propre au projet.

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <UserSecretsId>79a3edd0-2092-40a2-a04d-dcb46d5ca9ed</UserSecretsId>
</PropertyGroup>

Dans Visual Studio, cliquez avec le bouton droit sur le projet dans Explorateur de solutions, puis sélectionnez Gérer les secrets utilisateur dans le menu contextuel. Ce mouvement ajoute un UserSecretsId élément, rempli avec un GUID, au fichier projet.

Définir un secret

Définissez un secret d’application composé d’une clé et de sa valeur. Le secret est associé à la valeur du UserSecretsId projet. Par exemple, exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets set "Movies:ServiceApiKey" "12345"

Dans l’exemple précédent, le signe deux-points indique qu’il Movies s’agit d’un littéral d’objet avec une ServiceApiKey propriété.

L’outil Gestionnaire de secrets peut également être utilisé à partir d’autres répertoires. Utilisez l’option --project pour fournir le chemin d’accès du système de fichiers auquel le fichier projet existe. Par exemple :

dotnet user-secrets set "Movies:ServiceApiKey" "12345" --project "C:\apps\WebApp1\src\WebApp1"

JSAplatissement de structure ON dans Visual Studio

Le mouvement Gérer les secrets utilisateur de Visual Studio ouvre un secrets.json fichier dans l’éditeur de texte. Remplacez le contenu de secrets.json par les paires clé-valeur à stocker. Par exemple :

{
  "Movies": {
    "ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
    "ServiceApiKey": "12345"
  }
}

La JSstructure ON est aplatit après des modifications via dotnet user-secrets remove ou dotnet user-secrets set. Par exemple, l’exécution dotnet user-secrets remove "Movies:ConnectionString" réduit le littéral de l’objet Movies . Le fichier modifié ressemble à ce qui suit JSON :

{
  "Movies:ServiceApiKey": "12345"
}

Définir plusieurs secrets

Un lot de secrets peut être défini en pipant JSON sur la set commande . Dans l’exemple suivant, le input.json contenu du fichier est dirigé vers la set commande .

Ouvrez un interpréteur de commandes et exécutez la commande suivante :

type .\input.json | dotnet user-secrets set

Accéder à un secret

Pour accéder à un secret, effectuez les étapes suivantes :

  1. Inscrire la source de configuration des secrets utilisateur
  2. Lire le secret via l’API de configuration

Inscrire la source de configuration des secrets utilisateur

Le fournisseur de configuration des secrets utilisateur inscrit la source de configuration appropriée auprès de l’API de configuration .NET.

Les applications web ASP.NET Core créées avec dotnet new ou Visual Studio génèrent le code suivant :

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

WebApplication.CreateBuilder initialise une nouvelle instance de la classe WebApplicationBuilder avec les valeurs par défaut préconfigurées. L’initialisé WebApplicationBuilder (builder) fournit la configuration par défaut et les appels AddUserSecrets lorsque est Development:EnvironmentName

Lire le secret via l’API de configuration

Considérez les exemples suivants de lecture de la Movies:ServiceApiKey clé :

Fichier Program.cs :

var builder = WebApplication.CreateBuilder(args);
var movieApiKey = builder.Configuration["Movies:ServiceApiKey"];

var app = builder.Build();

app.MapGet("/", () => movieApiKey);

app.Run();

Razor Modèle de page pages :

public class IndexModel : PageModel
{
    private readonly IConfiguration _config;

    public IndexModel(IConfiguration config)
    {
        _config = config;
    }

    public void OnGet()
    {
        var moviesApiKey = _config["Movies:ServiceApiKey"];

        // call Movies service with the API key
    }
}

Pour plus d’informations, consultez Configuration dans ASP.NET Core.

Mapper des secrets à un POCO

Le mappage d’un littéral d’objet entier à un POCO (une classe .NET simple avec des propriétés) est utile pour l’agrégation des propriétés associées.

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Pour mapper les secrets précédents à un POCO, utilisez la fonctionnalité de liaison de graphe d’objets de l’API .NET Configuration. Le code suivant est lié à un POCO personnalisé MovieSettings et accède à la valeur de propriété ServiceApiKey :

var moviesConfig = 
    Configuration.GetSection("Movies").Get<MovieSettings>();
_moviesApiKey = moviesConfig.ServiceApiKey;

Les Movies:ConnectionString secrets et Movies:ServiceApiKey sont mappés aux propriétés respectives dans MovieSettings:

public class MovieSettings
{
    public string ConnectionString { get; set; }

    public string ServiceApiKey { get; set; }
}

Remplacement de chaînes par des secrets

Le stockage des mots de passe en texte brut n’est pas sécurisé. Par exemple, une chaîne de connexion de base de données stockée dans appsettings.json peut inclure un mot de passe pour l’utilisateur spécifié :

{
  "ConnectionStrings": {
    "Movies": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;User Id=johndoe;Password=pass123;MultipleActiveResultSets=true"
  }
}

Une approche plus sécurisée consiste à stocker le mot de passe en tant que secret. Par exemple :

dotnet user-secrets set "DbPassword" "pass123"

Supprimez la Password paire clé-valeur de la chaîne de connexion dans appsettings.json. Par exemple :

{
  "ConnectionStrings": {
    "Movies": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;User Id=johndoe;MultipleActiveResultSets=true"
  }
}

La valeur du secret peut être définie sur la propriété d’un SqlConnectionStringBuilderPassword objet pour compléter la chaîne de connexion :

using System.Data.SqlClient;

var builder = WebApplication.CreateBuilder(args);

var conStrBuilder = new SqlConnectionStringBuilder(
        builder.Configuration.GetConnectionString("Movies"));
conStrBuilder.Password = builder.Configuration["DbPassword"];
var connection = conStrBuilder.ConnectionString;

var app = builder.Build();

app.MapGet("/", () => connection);

app.Run();

Répertorier les secrets

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets list

Vous obtenez la sortie suivante :

Movies:ConnectionString = Server=(localdb)\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true
Movies:ServiceApiKey = 12345

Dans l’exemple précédent, un signe deux-points dans les noms de clés indique la hiérarchie d’objets dans secrets.json.

Supprimer un seul secret

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets remove "Movies:ConnectionString"

Le fichier de l’application secrets.json a été modifié pour supprimer la paire clé-valeur associée à la MoviesConnectionString clé :

{
  "Movies": {
    "ServiceApiKey": "12345"
  }
}

dotnet user-secrets list affiche le message suivant :

Movies:ServiceApiKey = 12345

Supprimer tous les secrets

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets clear

Tous les secrets utilisateur de l’application ont été supprimés du secrets.json fichier :

{}

L’exécution dotnet user-secrets list affiche le message suivant :

No secrets configured for this application.

Gérer les secrets utilisateur avec Visual Studio

Pour gérer les secrets utilisateur dans Visual Studio, cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions et sélectionnez Gérer les secrets utilisateur :

Visual Studio montrant Gérer les secrets utilisateur

Migration des secrets utilisateur de ASP.NET Framework vers ASP.NET Core

Consultez ce problème GitHub.

Ressources supplémentaires

Par Rick Anderson, Kirk Larkin, Daniel Roth et Scott Addie

Affichez ou téléchargez l’exemple de code (procédure de téléchargement)

Ce document explique comment gérer des données sensibles pour une application ASP.NET Core sur un ordinateur de développement. Ne stockez jamais de mots de passe ou d’autres données sensibles dans le code source. Les secrets de production ne doivent pas être utilisés pour le développement ou le test. Les secrets ne doivent pas être déployés avec l’application. Au lieu de cela, les secrets de production doivent être accessibles via un moyen contrôlé, comme les variables d’environnement ou azure Key Vault. Vous pouvez stocker et protéger les secrets de test et de production Azure avec le fournisseur de configuration Azure Key Vault.

Variables d'environnement

Les variables d’environnement sont utilisées pour éviter le stockage des secrets d’application dans le code ou dans les fichiers de configuration locaux. Les variables d’environnement remplacent les valeurs de configuration pour toutes les sources de configuration spécifiées précédemment.

Prenons l’exemple d’une application web ASP.NET Core dans laquelle la sécurité des comptes d’utilisateur individuels est activée. Une chaîne de connexion de base de données par défaut est incluse dans le fichier du appsettings.json projet avec la clé DefaultConnection. La chaîne de connexion par défaut est pour LocalDB, qui s’exécute en mode utilisateur et ne nécessite pas de mot de passe. Pendant le déploiement de l’application, la valeur de clé DefaultConnection peut être remplacée par la valeur d’une variable d’environnement. La variable d’environnement peut stocker la chaîne de connexion complète avec des informations d’identification sensibles.

Avertissement

Les variables d’environnement sont généralement stockées dans du texte brut non chiffré. Si la machine ou le processus est compromis, les variables d’environnement sont accessibles par des parties non approuvées. Des mesures supplémentaires pour empêcher la divulgation de secrets utilisateur peuvent être nécessaires.

Le séparateur : ne fonctionne pas avec les clés hiérarchiques des variables d’environnement sur toutes les plateformes. Le double trait de soulignement __ est :

  • Pris en charge par toutes les plateformes. Par exemple, le séparateur : n’est pas pris en charge par Bash, mais __ est pris en charge.
  • Remplacé automatiquement par :

Gestionnaire de secrets

L’outil Secret Manager stocke les données sensibles pendant le développement d’un projet ASP.NET Core. Dans ce contexte, un élément de données sensibles est un secret d’application. Les secrets d’application sont stockés dans un emplacement distinct de l’arborescence du projet. Les secrets d’application sont associés à un projet spécifique ou partagés entre plusieurs projets. Les secrets d’application ne sont pas archivés dans le contrôle de code source.

Avertissement

L’outil Gestionnaire de secrets ne chiffre pas les secrets stockés et ne doit pas être traité comme un magasin approuvé. C’est à des fins de développement uniquement. Les clés et les valeurs sont stockées dans un JSfichier de configuration ON dans le répertoire du profil utilisateur.

Fonctionnement de l’outil Secret Manager

L’outil Gestionnaire de secrets masque les détails de l’implémentation, tels que l’emplacement et la façon dont les valeurs sont stockées. Vous pouvez utiliser l’outil sans connaître ces détails d’implémentation. Les valeurs sont stockées dans un JSfichier ON dans le dossier de profil utilisateur de l’ordinateur local :

Chemin du système de fichiers :

%APPDATA%\Microsoft\UserSecrets\<user_secrets_id>\secrets.json

Dans les chemins d’accès de fichier précédents, remplacez par <user_secrets_id> la UserSecretsId valeur spécifiée dans le fichier projet.

N’écrivez pas de code qui dépend de l’emplacement ou du format des données enregistrées avec l’outil Secret Manager. Ces détails d’implémentation peuvent changer. Par exemple, les valeurs de secret ne sont pas chiffrées, mais peuvent l’être à l’avenir.

Activer le stockage des secrets

L’outil Secret Manager fonctionne sur les paramètres de configuration propres au projet stockés dans votre profil utilisateur.

L’outil Secret Manager inclut une init commande dans le SDK .NET Core 3.0.100 ou version ultérieure. Pour utiliser des secrets utilisateur, exécutez la commande suivante dans le répertoire du projet :

dotnet user-secrets init

La commande précédente ajoute un UserSecretsId élément dans un PropertyGroup du fichier projet. Par défaut, le texte interne de UserSecretsId est un GUID. Le texte interne est arbitraire, mais est propre au projet.

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <UserSecretsId>79a3edd0-2092-40a2-a04d-dcb46d5ca9ed</UserSecretsId>
</PropertyGroup>

Dans Visual Studio, cliquez avec le bouton droit sur le projet dans Explorateur de solutions, puis sélectionnez Gérer les secrets utilisateur dans le menu contextuel. Ce mouvement ajoute un UserSecretsId élément, rempli avec un GUID, au fichier projet.

Définir un secret

Définissez un secret d’application constitué d’une clé et de sa valeur. Le secret est associé à la valeur du UserSecretsId projet. Par exemple, exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets set "Movies:ServiceApiKey" "12345"

Dans l’exemple précédent, le signe deux-points indique qu’il Movies s’agit d’un littéral d’objet avec une ServiceApiKey propriété .

L’outil Gestionnaire de secrets peut également être utilisé à partir d’autres répertoires. Utilisez l’option --project pour fournir le chemin du système de fichiers au niveau duquel le fichier projet existe. Par exemple :

dotnet user-secrets set "Movies:ServiceApiKey" "12345" --project "C:\apps\WebApp1\src\WebApp1"

JSAplatissement de structure ON dans Visual Studio

Le mouvement Gérer les secrets utilisateur de Visual Studio ouvre un secrets.json fichier dans l’éditeur de texte. Remplacez le contenu de secrets.json par les paires clé-valeur à stocker. Par exemple :

{
  "Movies": {
    "ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
    "ServiceApiKey": "12345"
  }
}

La JSstructure ON est aplatit après des modifications via dotnet user-secrets remove ou dotnet user-secrets set. Par exemple, l’exécution dotnet user-secrets remove "Movies:ConnectionString" réduit le littéral d’objet Movies . Le fichier modifié ressemble à la valeur ON suivante JS:

{
  "Movies:ServiceApiKey": "12345"
}

Définir plusieurs secrets

Un lot de secrets peut être défini en JSdirigeant ON vers la set commande . Dans l’exemple suivant, le input.json contenu du fichier est redirigé vers la set commande .

Ouvrez un interpréteur de commandes et exécutez la commande suivante :

type .\input.json | dotnet user-secrets set

Accéder à un secret

Pour accéder à un secret, procédez comme suit :

  1. Inscrire la source de configuration des secrets utilisateur
  2. Lire le secret via l’API de configuration

Inscrire la source de configuration des secrets utilisateur

Le fournisseur de configuration des secrets utilisateur inscrit la source de configuration appropriée auprès de l’API de configuration .NET.

La source de configuration des secrets utilisateur est automatiquement ajoutée en mode développement lorsque le projet appelle CreateDefaultBuilder. CreateDefaultBuilder appelle AddUserSecrets quand est EnvironmentNameDevelopment:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

Quand CreateDefaultBuilder n’est pas appelé, ajoutez explicitement la source de configuration des secrets utilisateur en appelant AddUserSecrets dans ConfigureAppConfiguration. Appelez AddUserSecrets uniquement lorsque l’application s’exécute dans l’environnement de développement, comme illustré dans l’exemple suivant :

public class Program
{
    public static void Main(string[] args)
    {
        var host = new HostBuilder()
            .ConfigureAppConfiguration((hostContext, builder) =>
            {
                // Add other providers for JSON, etc.

                if (hostContext.HostingEnvironment.IsDevelopment())
                {
                    builder.AddUserSecrets<Program>();
                }
            })
            .Build();
        
        host.Run();
    }
}

Lire le secret via l’API de configuration

Si la source de configuration des secrets utilisateur est inscrite, l’API de configuration .NET peut lire les secrets. L’injection de constructeur peut être utilisée pour accéder à l’API de configuration .NET. Prenons les exemples suivants de lecture de la Movies:ServiceApiKey clé :

Classe de démarrage :

public class Startup
{
    private string _moviesApiKey = null;

    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        _moviesApiKey = Configuration["Movies:ServiceApiKey"];
    }

    public void Configure(IApplicationBuilder app)
    {
        app.Run(async (context) =>
        {
            var result = string.IsNullOrEmpty(_moviesApiKey) ? "Null" : "Not Null";
            await context.Response.WriteAsync($"Secret is {result}");
        });
    }
}

Razor Modèle de page pages :

public class IndexModel : PageModel
{
    private readonly IConfiguration _config;

    public IndexModel(IConfiguration config)
    {
        _config = config;
    }

    public void OnGet()
    {
        var moviesApiKey = _config["Movies:ServiceApiKey"];

        // call Movies service with the API key
    }
}

Pour plus d’informations, consultez Configuration d’accès au démarrage et Configuration de l’accès dans Razor les pages.

Mapper des secrets à un POCO

Le mappage d’un littéral d’objet entier à un POCO (une classe .NET simple avec des propriétés) est utile pour l’agrégation des propriétés associées.

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Pour mapper les secrets précédents à un POCO, utilisez la fonctionnalité de liaison de graphe d’objets de l’API .NET Configuration. Le code suivant est lié à un POCO personnalisé MovieSettings et accède à la valeur de propriété ServiceApiKey :

var moviesConfig = 
    Configuration.GetSection("Movies").Get<MovieSettings>();
_moviesApiKey = moviesConfig.ServiceApiKey;

Les Movies:ConnectionString secrets et Movies:ServiceApiKey sont mappés aux propriétés respectives dans MovieSettings:

public class MovieSettings
{
    public string ConnectionString { get; set; }

    public string ServiceApiKey { get; set; }
}

Remplacement de chaînes par des secrets

Le stockage des mots de passe en texte brut n’est pas sécurisé. Par exemple, une chaîne de connexion de base de données stockée dans appsettings.json peut inclure un mot de passe pour l’utilisateur spécifié :

{
  "ConnectionStrings": {
    "Movies": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;User Id=johndoe;Password=pass123;MultipleActiveResultSets=true"
  }
}

Une approche plus sécurisée consiste à stocker le mot de passe en tant que secret. Par exemple :

dotnet user-secrets set "DbPassword" "pass123"

Supprimez la Password paire clé-valeur de la chaîne de connexion dans appsettings.json. Par exemple :

{
  "ConnectionStrings": {
    "Movies": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;User Id=johndoe;MultipleActiveResultSets=true"
  }
}

La valeur du secret peut être définie sur la propriété d’un SqlConnectionStringBuilderPassword objet pour compléter la chaîne de connexion :

public class Startup
{
    private string _connection = null;

    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        var builder = new SqlConnectionStringBuilder(
            Configuration.GetConnectionString("Movies"));
        builder.Password = Configuration["DbPassword"];
        _connection = builder.ConnectionString;

        // code omitted for brevity
    }

    public void Configure(IApplicationBuilder app)
    {
        app.Run(async (context) =>
        {
            await context.Response.WriteAsync($"DB Connection: {_connection}");
        });
    }
}

Répertorier les secrets

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets list

Vous obtenez la sortie suivante :

Movies:ConnectionString = Server=(localdb)\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true
Movies:ServiceApiKey = 12345

Dans l’exemple précédent, un signe deux-points dans les noms de clés indique la hiérarchie d’objets dans secrets.json.

Supprimer un seul secret

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets remove "Movies:ConnectionString"

Le fichier de l’application secrets.json a été modifié pour supprimer la paire clé-valeur associée à la MoviesConnectionString clé :

{
  "Movies": {
    "ServiceApiKey": "12345"
  }
}

dotnet user-secrets list affiche le message suivant :

Movies:ServiceApiKey = 12345

Supprimer tous les secrets

Supposons que le fichier de secrets.json l’application contient les deux secrets suivants :

{
  "Movies:ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=Movie-1;Trusted_Connection=True;MultipleActiveResultSets=true",
  "Movies:ServiceApiKey": "12345"
}

Exécutez la commande suivante à partir du répertoire dans lequel se trouve le fichier projet :

dotnet user-secrets clear

Tous les secrets utilisateur de l’application ont été supprimés du secrets.json fichier :

{}

L’exécution dotnet user-secrets list affiche le message suivant :

No secrets configured for this application.

Gérer les secrets utilisateur avec Visual Studio

Pour gérer les secrets utilisateur dans Visual Studio, cliquez avec le bouton droit sur le projet dans l’Explorateur de solutions et sélectionnez Gérer les secrets utilisateur :

Visual Studio montrant Gérer les secrets utilisateur

Migration des secrets utilisateur de ASP.NET Framework vers ASP.NET Core

Consultez ce problème GitHub.

Ressources supplémentaires