___ antwort4372409 ___
Ich bevorzuge es, meine Verbindungszeichenfolgen in der machine.config zu behalten.
Meine Verbindungszeichenfolgen sind in den Umgebungen DEV, QA und PROD unterschiedlich und wenn ich sie in der Datei web.config aufbewahre, könnte ich mein Zielverzeichnis nicht sicher wegblasen und den neuen Code kopieren. Oder ich muss daran denken, alles außer der web.config bereitzustellen, das verursacht Probleme, wenn andere Teile der web.config sich ändern.
Es hängt von Ihrer Situation ab, aber wenn es ein wenig kompliziert wird, ist das Risiko, die falsche Verbindungszeichenfolge in der falschen Umgebung zu haben, einfach zu groß. Wir hatten tatsächlich Situationen, in denen das Testen die falschen Datenbanken schlug, weil die Verbindungszeichenfolge versehentlich verschoben wurde. Machine.config wird für maschinenspezifische Elemente verwendet - daher der Name. Es wird nie von Maschine zu Maschine bewegt.
Also habe ich in meiner machine.config mehrere Verbindungszeichenfolgen wie blogConnString, forumConnString, projectxConnString, etc. Ich betrachte diese Mischeinstellung nicht für verschiedene Seiten, ich halte es für machine.config. p>
Sie haben sich Sorgen um die Sicherheit gemacht, ich glaube, sobald sie auf der Box sind, sind sie gleichermaßen gesichert. Wenn sich die Verbindungszeichenfolge jedoch in der Datei web.config befindet, endet sie normalerweise in der Quellcodeverwaltung, in den Schreibtischen des Entwicklers, in den Sicherungsdateien, in den Installationsplänen, in den Bereitstellungssets usw. Das macht web.config für mich weniger sicher.
>
Schließlich ist ein anderer Ansatz, es in einer völlig anderen Konfigurationsdatei zu haben (zB WebEnvironment.confg), auf die dann in Ihrer web.config verwiesen wird. Diese Datei befindet sich in einem Verzeichnis, das nicht physisch unter Ihrer Website liegt, sondern sich praktisch unter Ihrer Site befindet. Weitere Einzelheiten finden Sie HIER.
___ answer1184300 ___
Wenn die Sicherheit Ihre Hauptsorge ist, konzentrieren Sie sich darauf, die Datenbank- und Benutzerberechtigungen zu sperren. Der Sicherheitsunterschied zwischen web / machine.config ist minimal. Colins Antwort ist richtig. Ich hätte gewählt oder kommentiert, aber ich habe noch nicht den Moxie!
___ qstnhdr ___ Speichern von Verbindungszeichenfolgen in machine.config oder Speichern in web.config
___ answer1184193 ___
Ich würde immer mit web.config gehen, weil das dort jeder erwartet. Es macht keinen Sinn, der Person, die die Website warten muss, durch die Speicherung von Verbindungszeichenfolgen an einem ungewöhnlichen Ort Schwierigkeiten zu bereiten.
ZUSÄTZLICH
Aufgrund der zusätzlichen Informationen, dass das OP am Sicherheitsaspekt interessiert ist, und nicht wegen und allgemeinem Grund habe ich Folgendes hinzugefügt.
Ich würde immer noch keine Verbindungszeichenfolgen in der machine.config speichern. Wenn Sie das tun, hat jede .NET-Anwendung, die auf dem Computer ausgeführt wird, Zugriff auf Ihre Verbindungszeichenfolgen.
web.config ist eine geschützte Datei. IIS wird es standardmäßig nicht bereitstellen, es sei denn, Sie tun etwas, um es falsch zu konfigurieren.
___ answer1184212 ___
Ich persönlich würde niemals meine Verbindungszeichenfolgen in meiner machine.config-Datei speichern, nur in der web.config.
Sie sagen, es ist ein dedizierter Server, aber ist dieser Server für eine einzelne Webanwendung bestimmt?
Wenn nicht, haben Sie jetzt eine einzige Datei (machine.config), die Konfigurationsdaten effektiv für mehrere (wahrscheinlich nicht verwandte) Webanwendungen freigibt. Abhängig von der Anzahl dieser Anwendungen und wenn Sie sie jemals auf einen anderen Server verschieben mussten, könnte die Verwendung der machine.config sehr unordentlich werden.
Auch wenn der Server für eine einzelne Webanwendung vorgesehen ist, werden Sie wahrscheinlich Ihre Entwicklung und Tests auf anderen Rechnern durchführen. Da es sich bei der Datei "machine.config" normalerweise nicht um eine Datei handelt, die in der Dateigruppe eines ASP.NET-Webanwendungsprojekts enthalten ist, müssen Sie möglicherweise die ausführbare Datei "machine.config" für jeden der verschiedenen Dev / Tests bereitstellen / production machines, und stellen Sie sicher, dass andere (nicht auf Verbindungszeichenfolgen bezogene) Konfigurationen in ihnen für diese Maschine korrekt sind.
Die Verwendung von web.config zum Speichern von Datenbankverbindungszeichenfolgen ist logisch sinnvoll und wird von fast allen ASP.NET-Entwicklern erwartet, auch wenn Sie mehrere Anwendungen haben, die dieselbe Datenbank auf demselben Datenbankserver verwenden. Wenn diese Konfiguration in der Datei web.config jeder Anwendung beibehalten wird, ist jede dieser Anwendungen eigenständiger und nicht von einer anderen "externen" Datei abhängig.
Ich sehe generell die machine.config und etwas, das das Framework selbst verwendet, und es gehört zu einer Maschine und ist spezifisch für diese Maschine. Ich gehe sehr selten hinein und berühre es selbst. Ich sehe die Datei web.config als eine Datei, die Teil Ihres Webanwendungsprojekts ist und sich mit diesem Projekt "bewegt", wenn es verschoben wird und auf verschiedenen Computern bereitgestellt wird.
Vergessen Sie außerdem nicht, dass viele der in der Datei machine.config definierten Elemente pro Anwendung überschrieben werden können, indem bestimmte Konfigurationselemente in der Datei web.config einer bestimmten Anwendung neu definiert werden.
Natürlich gibt es ein paar gute Gründe, Ihre machine.config-Datei zu bearbeiten / ändern (so wie mehrere Web-Server in einer Webfarm wahrscheinlich Dinge wie Verschlüsselungs- / Entschlüsselungsschlüssel innerhalb der machine.config benötigen, um synchronisiert zu werden), Ich glaube jedoch nicht, dass Datenbankverbindungszeichenfolgen einer dieser gültigen Gründe sind.
___ answer1184250 ___
Im Hinblick auf die Sicherheit könnten Sie Ihre Verbindungszeichenfolgen in einer eigenen verschlüsselten .config-Datei speichern, auf die Ihre Datei web.config verweisen würde.
___ answer18697680 ___
alle guten Punkte. In meiner Umgebung werden Datenbanken gemeinsam genutzt, sodass das Speichern in einer web.config Redundanz erzwingt. Wir verwenden hier Standard-SQL-Datenbanken, auf die alle zugreifen. Eine separate Konfigurationsdatei wird bevorzugt. Dies ermöglicht die Standardisierung, Sicherheit und die Beseitigung der Notwendigkeit, die web.config zu ändern, wenn eine App bereitgestellt wird.
___ tag123connectionstring ___ Eine Zeichenfolge, die Informationen enthält, die für die Verbindung mit einem Dienst benötigt werden, normalerweise Datenbank.
___ tag123configurationfiles ___ Dateien, die die Anfangseinstellungen für einige Computerprogramme konfigurieren.
___ answer15817615 ___
Hier gibt es viele gute Punkte. Die Umgebung von JBrooks kommt mir am nächsten, aber am Ende stimme ich nicht überein, Verbindungszeichenfolgen in Machine.config zu setzen.
Ich stimme OJ zu, aber nicht aus dem Grund, den er hier zitiert. Ich würde darauf hinweisen, dass, wie JBrooks sagte, Verbindungszeichenfolgen höchstwahrscheinlich unterschiedliche Anmeldeinformationen in Entwicklungs- und Produktionsumgebungen verwenden. Unsere Intranet-Entwicklungsdatenbanken verfügen zum Beispiel alle über die gleichen einfachen Anmeldeinformationen, während unsere Produktionsdatenbanken jeweils unterschiedliche Anmeldeinformationen mit komplexen Kennwörtern haben. Es gibt also gute Gründe, die Verbindungszeichenfolgen nicht in der Datei Web / App.config zu speichern, sondern in einer Datei, die lokal auf dem Zielserver liegt. Ich mag die Registrierung, ich selbst, aber ich weiß, dass das überhaupt nicht unterstützt wird. Die Datei "Machine.config" dient eindeutig als Lösung.
Nein, ich stimme OJ zu, da sich Machine.config im .NET-Framework befindet und von Microsoft geändert werden könnte. Aber Microsoft weiß nichts von der Datei %code% auf unseren Produktionsservern. Diese Datei wird von Web / App.config-Dateien geladen mit:
%code%
blowdart machte den Punkt über Verschlüsselung - immer eine gute Idee. Aber am Ende können Sie Ihre Datenbankanmeldedaten nur dann vollständig schützen, wenn Sie sie regelmäßig ändern.
___ tag123aspnet ___ ASP.NET ist ein Framework für die Entwicklung von Microsoft-Webanwendungen, mit dem Programmierer dynamische Websites, Webanwendungen und Webdienste erstellen können. Es ist nützlich, dieses Tag in Verbindung mit dem Typ des Projekttyps zu verwenden, z. [asp.net-mvc], [asp.net-webforms] oder [asp.net-web-api]. Verwenden Sie dieses Tag NICHT für Fragen zu ASP.NET Core - verwenden Sie stattdessen [asp.net-core].
___ qstntxt ___
Ist es für einen dedizierten Server besser, die Verbindungszeichenfolge in web.config oder machine.config zu speichern? Was sind die Vor- und Nachteile jedes Ansatzes?
Danke
Edit: Ich bin besorgt über die Sicherheit hier, also ist die Frage, welcher Ansatz sicherer ist.
___