Puis-je Ajouter ConnectionStrings à la ConnectionStringCollection au moment de l'Exécution?

Est-il un moyen où je peux ajouter une chaîne de connexion à la ConnectionStringCollection retourné par le ConfigurationManager à l'exécution dans un Asp.Net application?

J'ai essayé ce qui suit, mais me dit que le fichier de configuration est en lecture seule.

ConfigurationManager.ConnectionStrings.Add(new ConnectionStringSettings(params));

Est-il une autre façon de le faire au moment de l'exécution? Je sais qu'au moment de la conception, je peux ajouter une chaîne de connexion au web.config; cependant, je suis à la recherche d'ajouter un élément à la collection au moment de l'exécution.

Grâce

EDIT:
L'une des raisons pourquoi je suis tenté de faire, c'est en raison d'une exigence en matière de sécurité, qui m'empêche de placer ConnectionStrings dans le web.config (même cryptées). Je voudrais utiliser des éléments tels que l'Appartenance et Profils sur mon projet; cependant, je suis à la recherche dans une alternative pour faire de telles w/o la rédaction d'un fournisseur personnalisé. Fournisseur personnalisé ne sont pas si mauvais que ça, mais si je peux trouver une solution plus facile, je suis tout à fait pour.

Vous pouvez déplacer les chaînes de connexion de web.config. Voir les Meilleures pratiques pour le déploiement de mots de passe et autres données sensibles à ASP.NET et d'Azur de Sites web asp.net/identity/overview/features-api/...

InformationsquelleAutor JamesEggers | 2008-12-10

asp.net c#connection-string web-config

11
```
var cfg = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(@"/");
cfg.ConnectionStrings.ConnectionStrings.Add(new ConnectionStringSettings(params));

cfg.Save();
```
Être Conseillé ce sera la cause de votre site web à recycler car il modifie le fichier de configuration. Découvrez http://msdn.microsoft.com/en-us/library/4c2kcht0(SV.80).aspx
- La motivation pour la question était de déplacer la chaîne de connexion de web.config - qui est une des meilleures pratiques de sécurité parce que vous ne voulez pas de fuite de secrets à tout le monde avec l'accès au code source. Voir les Meilleures pratiques pour le déploiement de mots de passe et autres données sensibles à ASP.NET et d'Azur de Sites web asp.net/identity/overview/features-api/...
InformationsquelleAutor JoshBerke
25

Vous pouvez utiliser la réflexion pour désactiver le privé bReadOnly champ (mauvaise idée, etc.):
```
typeof(ConfigurationElementCollection)
    .GetField("bReadOnly", BindingFlags.Instance | BindingFlags.NonPublic)
    .SetValue(ConfigurationManager.ConnectionStrings, false);
ConfigurationManager.ConnectionStrings.Add(new ConnectionStringSettings());
```
Ceci est similaire à la technique nécessaire pour modifier une connexion existante chaîne, et ajouté comme commentaire par Brian Rodgers.
- Génial hack! Vous avez raison, c'est une mauvaise idée - mais il fonctionne pour l'ajout de con dod. La motivation de la question est comment faire pour supprimer conStrs à partir du web.config - qui est une des meilleures pratiques de sécurité de sorte que les secrets ne coule pas de source code. Voir asp.net/identity/overview/features-api/... pour les déplacer ( les Meilleures pratiques pour le déploiement de mots de passe et autres données sensibles à ASP.NET et d'Azur de Sites web)
- Merci! ce qui est excellent pour les tests unitaires
InformationsquelleAutor user423430
10

Signalons simplement celui qui vous a donné la "sécurité" que vous ne pouvez pas placer la chaîne de connexion dans le web.la config est un idiot. Le web.config ne peut jamais être consulté par autre chose que votre application ou l'accès à distance au serveur.

Cela sonne tout à fait comme un problème et doit être résolu là.
- J'ai essayé sur celui-ci. Cette exigence est venue de l'équipe en charge de la DMZ de sécurité et ne veut pas risquer d'avoir exposé dans le cas d'une machine de culasse...même dans un état chiffré puisqu'ils auraient la clé machine à ce point dans le pire des cas ainsi.
- Hmm, si ils ont manqué à cette boîte, ils vont trouver votre serveur SQL assez tôt...vous devez avoir de la chaîne de connexion sur le serveur, dans une certaine forme ou d'une autre...c'est un idiot exigence
- Je suis entièrement d'accord avec Josh, une fois qu'ils la racine de votre serveur web, votre base de données sera bientôt le cas. Ce sont protégées par des systèmes de détection d'intrusion que vous avez un changement à désactiver vos serveurs qui est, à ce point de la tromper que la preuve de la solution à la base de données est compromise.
- Je ressens votre douleur, mais les informations d'identification de l'ASP.NET l'utilisateur doit avoir le droit à une quelconque méthode de votre code utilise pour obtenir la chaîne de connexion. Donc, même si votre code personnalisé est l'obtention de la chaîne de connexion à partir d'un serveur distant ou via un webservice, le pirate sera en mesure d'utiliser la même méthode.
- web.la config est considéré comme le code source, et les secrets ne doivent jamais être vérifié dans les sources consultez les Meilleures pratiques pour le déploiement de mots de passe et autres données sensibles à ASP.NET et d'Azur de Sites web asp.net/identity/overview/features-api/...
- que le simple fait de les stocke dans un distinct fichier de configuration. Nulle part n'ai-je dire les chaînes de connexion doit est inscrit dans votre système de contrôle de source.
- distinct fichier de configuration est pratiquement impossible à obtenir dans le contrôle de code source et de nos secrets de la source de contrôle. web.la config est la partie de votre source, vous dites qu'il ne serait pas sous contrôle de code source? Le web.config avec des secrets peut être consulté par toute personne ayant accès à votre contrôle de code source, qui est pourquoi vous déplacer.
- Vous agissez comme si vous ne pouvez pas avoir un processus de construction qui se fond dans la configuration des données à partir d'un jardin clos de murs. Ils ont construit l'ensemble de la config concept de transformation directement atteindre cet objectif. Cette question était juste formulée très mal que l'on a accepté la réponse contredit la prémisse de la question qui consiste à ajouter directement les données sur le web.config (qui valide ma réponse, c'est idiot de ne pas les mettre dans le web.config). En fin de compte, peu importe ce que les clés existent sur le disque quelque part à un moment donné. Probablement quelque part tout le temps, pour permettre appuie sans intervention humaine.
- Qui sont ils? MME de sécurité recommande l'approche que j'ai documenté. Sur private disk est mieux que de source publique. Lire mon Meilleures pratiques pour le déploiement de mots de passe et autres données sensibles à ASP.NET et d'Azur de Sites web asp.net/identity/overview/features-api/... qui a été approuvée par l'équipe de sécurité. Pensez à mettre à jour votre réponse qui laisse une fuite via GIT grande ouverte.
- Sur mon Azure serveur de build, j'utilise powershellcookbook.com/recipe/PukO/... pour chiffrer les informations d'identification de disque - mais alors je n'ai qu'dev/test pw, pas de production de pw. Veuillez mettre à jour votre réponse à votre affirmation "celui qui vous a donné la "sécurité" que vous ne pouvez pas placer la chaîne de connexion dans le web.la config est un idiot. Le web.config ne peut jamais être consulté par n'importe quoi" est incorrect, car il omet pw fuite par tout le monde avec un accès à la source, la fuite via GIT, etc.
- absolument pas changer ma réponse. Vous êtes l'amalgame entre les deux problématiques bien distinctes. Contrôle de code Source contenant les clés vs le web.config contenant la clé. Pas d'où vient cette question de parler en gardant les touches de contrôle de code source, il a été purement propos de les garder hors de la web.config lui-même, ce qui est ridicule. La accepté de répondre à la question uniquement les met dans le web.config. Méthodes pour garder les clés de contrôle de source sont totalement étrangères à ce qui a été spécifiquement demandé.
- Votre affirmation "Le web.config ne peut jamais être consulté par autre chose que votre application ou l'accès à distance au serveur." rate le problème de fuites - pas d'où vous le signaler. Pas de où pouvez-vous dire de ne pas rechercher le web.config dans la source ou de la variante de l'utilisation d'une transformation qui n'est pas vérifié. Vous appelez à une meilleure pratique de sécurité "idiot" parce que vous avez raté le problème des fuites.
- une fois de plus pour la millième fois, l'OP ne s'est jamais posé la question de comment ne pas consulter les clés dans le contrôle de source. C'est peut-être ce qu'il voulait dire, qui sait? Je n'ai pas de boule de cristal. J'ai répondu à la question qui leur était posée.
- C'est parce que, comme vous, ne savait pas que les fuites de mots de passe. Maintenant que vous savez il y a une fuite de mots de passe et vous savez que votre affirmation "la "sécurité" que vous ne pouvez pas placer la chaîne de connexion dans le web.la config est un idiot." est incorrect, pourquoi ne pas mettre à jour votre réponse. Vous devez inclure au moins, pendant qu'IIS ne pas servir un .fichier de configuration, vous pouvez fuite IPL à partir de la source.Avez-vous lu mon asp.net/identity/overview/features-api/... et si oui, de quelle partie tu ne comprends pas?
- Marisic vous affirmer "en fin de compte, peu importe ce que les clés existent sur le disque quelque part à un moment donné. Probablement quelque part tout le temps, pour permettre appuie sans intervention humaine." C'est incorrect. J'utilise powershellcookbook.com/recipe/PukO/... pour stocker chiffré PW sur le disque pour les sans surveillance s'appuie.
- hypothèses sont carrément erronée. Il suffit de cesser. L'OP spécifiquement diminué config de chiffrement. Votre solution à l'aide d'Azure, devinez quoi? Ces clés sont assis sur le disque dans Azure quelque part (je l'espère crypté).... "pour permettre l'appuie sans intervention humaine". Vous êtes de juxtaposer sans rapport avec les choses de plus et plus et plus de nouveau. N où ai-je dit de les touches que ce soit. Peu importe comment vous le faites de gestion des clés d'une personne avec les droits suffisants accès. Même avec la configuration de chiffrement de la personne qui peut tirer le cert hors de la boîte peut déchiffrer les clés.
InformationsquelleAutor Chris Marisic
4

Si vous essayez de modifier les chaînes de connexion dans votre site web.config lors de l'exécution de prendre un coup d'oeil à WebConfigurationManager.

Si vous essayez juste de modifier la configuration lors de l'exécution d'injecter une chaîne de connexion alors que vous êtes hors de la chance. Le ConfigurationManager objet de l'arbre est destiné à être un reflet direct de fichiers de configuration, si vous étiez en mesure de modifier que l'état serait alors incompatible.

Je recommande la création d'une simple façade de classe que vous pouvez utiliser pour récupérer vos chaînes de connexion. De cette façon, vous pourriez avoir la façade retourner une chaîne de connexion à partir de votre sur la mouche de la collection ou si l'un n'existe pas alors qu'il pourrait le saisir à partir de la ConfigurationManager.
```
class ConnectionStringProvider
{
    Dictionary<string, System.Configuration.ConnectionStringSettings> _localStrings = new Dictionary<string, System.Configuration.ConnectionStringSettings>();

    public void AddLocalConnectionString(string name, string connstring)
    {
        System.Configuration.ConnectionStringSettings cs = new System.Configuration.ConnectionStringSettings(name, connstring);
        _localStrings.Add(name, cs);
    }

    public void RemoveLocalConnectionString(string name)
    {
        _localStrings.Remove(name);
    }

    public System.Configuration.ConnectionStringSettings this[string name] {
        get 
        { 
            return _localStrings.ContainsKey(name) ? _localStrings[name] : System.Configuration.ConfigurationManager.ConnectionStrings[name]; 
        }
    }
}
```
Ou vous pouvez toujours aller un peu plus lourd et d'utiliser quelque chose comme l'Entreprise de Configuration de la Bibliothèque de Bloc.

InformationsquelleAutor joshperry
1

N'avez pas encore essayé, mais peut-être vous pouvez modifier la valeur d'une chaîne de connexion existante au moment de l'exécution? Par exemple, au lieu de:
```
ConfigurationManager.ConnectionStrings.Add(new ConnectionStringSettings(params));
```
Peut-être que vous pourriez faire quelque chose comme:
```
ConfigurationManager.ConnectionStrings["myconnection"].ConnectionString = "something";
```
Si oui, vous pouvez spécifier la chaîne de connexion "variables" dans la configuration, mais les mettre à false ou vide chaînes de connexion:
```
<add name="myconnection" connectionString="SET AT RUNTIME" ... />
```
- Je l'ai juste essayé et eu la même lecture seule erreur.
- Modification de réflexion: david.gardiner.net.au/2008/09/programmatically-setting.html
InformationsquelleAutor Scott Isaacs
1

La configuration de l'infrastructure prend en charge très robuste de cryptage à travers les Fenêtres DataProtection API qui utilise une machine spécifique clé pour chiffrer les sections de configuration. De cette façon, il ne serait pas possible de lire les données chiffrées n'importe où, mais sur l'ordinateur où il a été chiffré.

C'est la même API qui est utilisé pour le Gouvernement conforme lecteur/cryptage de dossiers dans Windows. Serait-ce le stand up au succès de votre entreprise exigences en matière de sécurité?

Soit manuellement ou par le biais de votre automatisation du déploiement, vous pouvez exécuter cette commande pour chiffrer la section connectionStrings de votre site web.config pour une application web spécifique.
```
aspnet_regiis -pe "connectionStrings" -app "/MyCoolWebApplication" -prov "DataProtectionConfigurationProvider"
```
InformationsquelleAutor joshperry
1

Si vous utilisez MS SQL, vous pouvez configurer votre serveur web pour accéder à SQL Server via l'authentification windows, de sorte que vous ne jamais avoir tous les mots de passe dans vos webconfig, ou même flottant autour dans votre mémoire de l'application.

InformationsquelleAutor Kibbee
0

Non, vous ne pouvez pas modifier le fichier de configuration au moment de l'exécution, il n'est pas prévu pour cela.
Vous pourriez peut-être utiliser les Bibliothèques d'Entreprise de Configuration à faire.
- -1 n'est pas vrai du tout, il vous les causes de votre site à recycler.
- Ohh..allez!! Assurez-vous que vous pouvez c'est un fichier xml, mais c'est une très mauvaise pratique. .NET n'est pas une API pour modifier les fichiers de configuration....demandez-vous pourquoi. "-)
- incorrecte de nouveau, il n'a absolument Api pour modifier les fichiers de configuration OpenWebConfiguration/Save stackoverflow.com/a/719941/37055
- Ne le savais pas. La réponse est assez vieux et de toute façon je pense (à mon humble avis) c'est pas une bonne pratique à suivre.
- même accepté la réponse est ici OpenWebConfiguration, paradoxalement, je n'ai pas faites défiler vers le haut avant de les lier à une autre question. J'ai certainement d'accord avec vous que tout le monde ne devrait pas de le faire, mais ne peut pas est un absolu. Absolus sont presque toujours tort dans chaque situation, dans le logiciel... sauf s'il s'agit d'Oracle, mais je m'égare
InformationsquelleAutor ema

Vous devez vous connecter pour publier un commentaire.