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 :
- Inscrire la source de configuration des secrets utilisateur
- 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 :
Migration des secrets utilisateur de ASP.NET Framework vers ASP.NET Core
Consultez ce problème GitHub.
Ressources supplémentaires
- Consultez ce problème pour plus d’informations sur l’accès aux secrets utilisateur à partir d’IIS.
- Configuration dans ASP.NET Core
- Fournisseur de configuration Azure Key Vault dans ASP.NET Core
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 :
- Inscrire la source de configuration des secrets utilisateur
- 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 :
Migration des secrets utilisateur de ASP.NET Framework vers ASP.NET Core
Consultez ce problème GitHub.
Ressources supplémentaires
- Consultez ce problème pour plus d’informations sur l’accès aux secrets utilisateur à partir d’IIS.
- Configuration dans ASP.NET Core
- Fournisseur de configuration Azure Key Vault dans ASP.NET Core