Speichern von Verbindungszeichenfolgen in der Maschine.config vs speichert Sie in web.config

Für einen dedizierten server, ist es besser, speichern Sie die Verbindungszeichenfolge in der web.config oder machine.config? was die Vorteile und Nachteile des jeweiligen Ansatzes?

Dank

Edit: ich bin besorgt über die Sicherheit hier, also, die Frage ist, welcher Ansatz mehr sicher.

InformationsquelleAutor Waleed Eissa | 2009-07-26
  1. 10

    Ich würde immer gehen mit web.config mit der Begründung, dass das ist, wo jeder es erwarten würde. Es gibt keinen Sinn, dass die person, die zu pflegen der web-site keinerlei weitere Schwierigkeiten durch speichern von Verbindungszeichenfolgen in einem ungewöhnlichen Ort.

    ZUSÄTZLICHE

    Basierend auf der zusätzlichen information, dass der OP ist daran interessiert, den Aspekt Sicherheit eher als und Allgemeinen Grund, den ich Hinzugefügt haben, die folgenden.

    Ich würde immer noch nicht zum speichern von Verbindungszeichenfolgen in der Maschine.config. Wenn Sie tun, dass jeder .NET-Anwendung läuft auf dem Rechner Zugang hat Ihre connection strings.

    web.config ist eine geschützte Datei. IIS nicht servieren es standardmäßig, wenn Sie etwas tun, um misconfigure es.

    • Ich bin damit einverstanden. Halten Sie es einfach. Und nicht nur für andere, für sich selbst, auch.
    • Ich bin eigentlich pflegen die Website selbst, so ist dies kein problem.
    • Meine Empfehlung: macht keine Erwähnung, wer der verantwortliche ist. Auch wenn du es bist, meine Empfehlung steht noch immer. Halten Sie die Dinge einfach. 6 Monate unten die Zeile, die Sie vielleicht vergessen haben.
    • Ich werde nicht vergessen, versprochen 🙂 .. im ernst, der Punkt in der Frage ist zu wissen, welche Ansatz ist sicherer und warum. Es scheint mir Maschine.config kann ein wenig mehr Sicherheit als der web.config. Sicherheit ist mein eigentliches Anliegen hier.
    • Dann möchten Sie vielleicht zu Bearbeiten, auf Ihre Frage zu reflektieren, dass Sie mehr daran interessiert sind, den Aspekt der Sicherheit.
    • Es ist nicht so sehr IIS/ASP.NET serving it up (es gibt zwar eine Möglichkeit, es könnte ein Fehler sein), sollte die Sorge, aber Ihren eigenen code. Skripte dienen Dateien, die nicht mehr relative Pfade zu berücksichtigen sind ein wunderbarer Weg, um Zugang zum web.config.
    • interessanter Punkt. Dies scheint wie ein guter Grund zu prüfen, Maschine.config
    • alles, was ich hier gelesen hab gibt nicht verwenden Maschine.config. Es ist völlig nicht-standard -
    • Habe ich auch geändert die id der ASPNET-Prozess gehostet wird zu einem domain-Konto. Dann nutzen Sie die integrierte Sicherheit, und geben Sie diesem Konto das absolute minimum an Sicherheit, die es braucht um die Arbeit zu erledigen (Gewährung dbadm schlecht ist).
    • S, eigentlich bin ich mit MySQL, also keine integrierte Sicherheit mit, dass
    • Gibt es trotzdem, es kann gespeichert werden im IIS? so, dass alle website kann der Zugriff auf die Datenbank ( ich habe nur einen webserver mit 10 websites und ich möchte nicht, dass Programmierer, um änderungen an web.config, oder auch wenn Sie es tun, ich will nicht mit Ihnen, so sehen Sie es)
    • Wenn die Programmierer haben Zugriff auf den Server auf eine Ebene, damit Sie sehen die web -.config-was ist dann das eigentliche Problem von Ihnen in der Lage, um zu sehen/ändern? Es scheint mir, dass du entweder muss ein operations-team zur Pflege der web.config oder Vertrauen die Entwickler auf den server zugreifen.

    InformationsquelleAutor Colin Mackay
  2. 9

    Ich behalte lieber meine connection strings in der Maschine.config.

    Meine Verbindung strings sind unterschiedlich zwischen DEV -, QA-und PROD-Umgebungen, und wenn ich hielt Sie in der web.config konnte ich nicht sicher wegblasen mein Ziel-Verzeichnis an und kopieren Sie den neuen code. Oder ich würde daran denken müssen, bereitstellen von allem, was aber die web.config, schafft dies Probleme, wenn andere Teile der web.config ändern.

    Es hängt von Ihrer situation, aber wenn wird es ein wenig kompliziert ist das Risiko, dass die falsche connection-string in der falschen Umgebung ist einfach zu groß. Wir haben schon Situationen gehabt, wo die Prüfung war, schlagen den falschen Datenbanken, weil Sie die Verbindungszeichenfolge wurde versehentlich verschoben. Maschine.config wird verwendet für die Maschinen-spezifische Elemente - daher der name. Es wird nie verschoben von Maschine zu Maschine.

    So, in meinem Rechner.config habe ich mehrere connection strings wie blogConnString, forumConnString, projectxConnString, etc. Ich denke nicht, dass diese mixing-Einstellung für verschiedene Websites, halte ich es für das halten der Maschine Einstellung der Maschine.config.

    Waren Sie besorgt über die Sicherheit, ich denke, sobald Sie auf das Feld, Sie sind ebenso gesichert. Aber wenn die Verbindungszeichenfolge in der web.config es endet in der Regel bis in die source-control, developer ' s Schreibtische, in backup-Dateien, die in installieren von Plänen, die Bereitstellung sets, etc. Dies macht das web.config Weg weniger sicher zu mir.

    Schließlich ein weiterer Ansatz ist, um es in eine völlig andere config-Datei (sagen WebEnvironment.confg), das ist dann auf die in Ihrer Website.config. Diese Datei würde sitzen in einem Verzeichnis, die nicht körperlich in Ihre web-site, aber ist praktisch unter Ihre Website. Weitere details sind HIER.

    • Sorry, aber ich bin völlig einverstanden mit diesem. Maschine Konfiguration geht in der Maschine.config, nicht Anwendung-Konfiguration. Datenbank-Verbindungszeichenfolgen sind anwendungsspezifisch, nicht in der Maschine spezifisch.
    • Wenn Sie Windows installieren, jetzt bekommen Sie ein Standard-Verbindungszeichenfolge in der Maschine.config - LocalSqlServer. Es ist die Maschine, Konfiguration Wert für die lokale SQL Express. Ich habe die Maschine, Konfiguration für meinen blog, meine Haupt-website, etc. Als Entwickler, es macht es so einfach.
    • Zu jedem gibt es eigene. Aber ich sehe nicht, "MS tun, damit es ok ist," als eine gute Begründung. Ich habe aufgehört zu zählen von dem schrecklichen code-Beispiele wurden auf der MSDN-website. Nur weil Sie es erstellt haben, bedeutet es nicht, dass Ihre Vorschläge auf, wie es zu benutzen sind die besten. Ich weiß auch nicht Graben der Schwerpunkt auf dem "making life easy für die Entwickler", aber das ist persönliche Präferenz. Es geht hier nicht um mich, es ist alles über die software.
    • Ich Stimme mit JBrooks. Config Einstellungen, Wechsel zwischen den Umgebungen sind ein großer Schmerz und es ist viel einfacher zu verwalten Umgebungen, wenn alle von denen sind in der Maschine.config anstelle des individuellen. Es macht Sinn für mich - auf unserem Testserver, ich will immer zeigen servicetest.example.com und auf der Produktion, ich will immer zeigen service.example.com. Warum will ich manuell pflegen Sie diese Einstellungen für jede Anwendung und auch über dupliziert zig Projekte?
    • Das ist genau das, was web.config-Transformationen sind für.
    • So würden Sie vertrauliche Informationen wie Produktions-Verbindungs-Zeichenfolgen (einschließlich Passwort) in die release-transform-Datei in Ihren source-code-repository, wo jeder Entwickler hat Zugriff auf die Produktion login-Daten?
    • FWIW, habe ich eigentlich tun würde dies, wie ich (und die organisation für die ich arbeite) vertraut die Entwickler mit solchen Informationen.
    • das ist sehr schön. Die Firma für die ich arbeite hat 300 Entwickler (von denen einige sind Auftragnehmer Mitarbeiter, die in der Regel kommen und gehen innerhalb von einigen Wochen), es ist also nicht so einfach, wie das Vertrauen in jedermann, als ideal, wie das sein kann. Es wäre unverantwortlich, Ihre Kunden und Ihre Sicherheit der Benutzer. In Großbritannien würden Sie gegen das Datenschutzgesetz (ico.org.uk/fuer-Organisationen/Anleitung-zu-Daten-Schutz/...)
    • Lesen Sie Punkt 3 Der 12-Faktor-App (12factor.net)

    InformationsquelleAutor JBrooks
  3. 5

    Ich, persönlich, würde nie meine Verbindungszeichenfolgen in meinem Rechner.config-Datei, die immer nur im web.config.

    Du sagst, es ist ein dedizierter server, aber dieser server für eine einzelne web-Anwendung?

    Wenn nicht, haben Sie jetzt eine einzelne Datei (machine.config) das ist der efziente Austausch von Konfigurationsdaten für mehrere (wahrscheinlich un-bezogene) web-Anwendungen. Je nach Anzahl der Anwendungen, und wenn Sie jemals benötigt, um Sie zu verschieben auf einen anderen server, mit der Maschine.config könnte sehr chaotisch.

    Selbst wenn der server ist gewidmet, um eine einzelne web-Anwendung, werden Sie wahrscheinlich ausführen Sie Ihre Entwicklung und Tests auf anderen Maschinen. Da die Maschine.config ist in der Regel nicht, dass eine Datei in der Datei-set, eine ASP.NET web-Anwendung-Projekt, werden Sie wahrscheinlich haben, um zu gehen aus dem Weg, der zum bereitstellen der Maschine.config für jedes der verschiedenen dev - /test - /Produktions-Maschinen, und sicherzustellen, dass andere (nicht-Verbindungs-string) bezogene Konfiguration in Ihnen ist das richtige für die Maschine.

    Über das web.config zum speichern von Datenbank-Verbindungszeichenfolgen macht durchaus einen logischen Sinn und ist völlig erwartet, von fast allen ASP.NET Entwickler, selbst wenn Sie mehrere Anwendungen haben, die genau die gleiche Datenbank auf der exakt gleichen Datenbank-server. Halten Sie diese Konfiguration in der web.in der config von jeder Anwendung ermöglicht es jedem, solche Anwendungen werden mehr eigenständig und nicht abhängig einige andere "außen" - Datei.

    Ich in der Regel anzeigen der Maschine.config und etwas, dass das framework selbst verwendet, und es gehört auf eine Maschine und ist spezifisch für die Maschine. Ich gehe sehr selten in Berührung und es mich. Ich sehe das web.config als Datei, ist Bestandteil Ihrer web-Anwendung-Projekt, und "bewegt" mit diesem Projekt, wie es sich bewegt und ist bereitgestellt, um verschiedene Maschinen.

    Auch nicht vergessen, dass eine Menge von dem, was ist definiert in der Maschine.config kann "außer Kraft gesetzt" auf einer basis pro Anwendung durch die Neudefinition bestimmten configuration-elements in einer bestimmten Anwendung web.config-Datei.

    Natürlich, es gibt ein paar triftige Gründe, um die Bearbeitung/änderung Ihrer Maschine.config-Datei (z.B. mehrere Webserver in einer Webfarm werden wahrscheinlich brauchen Dinge wie Verschlüsselung/Entschlüsselung Schlüssel innerhalb der Maschine.config synchronisiert werden), aber ich glaube nicht, dass Datenbank-Verbindungszeichenfolgen sind einer dieser Gründe.

    • Vielen Dank für deine ausführliche Antwort, es ist eine einfache web-Anwendung, die durch die Art und Weise.
    • Craig - ich verstehe deinen Punkt, aber ich denke, Sie sind nicht die Realität, die der Aufrechterhaltung einer großen Anzahl von Anwendungen, web-oder app-config. Wir haben 25+ Projekte, die auf einigen unserer Server, die alle enthalten die gleiche Datenbank-connection-string. Wir gehen zu müssen, um manuell aktualisieren Sie alle Verbindungszeichenfolgen, die in allen Projekten, um unsere DB-server einen neuen Hostnamen. In der Erwägung, dass, wenn Sie waren in die Maschine, config, wir könnten Sie an einem einzigen Ort.
    • Für Ihre gegebenen situation, das ist etwas ungewöhnlich, ich kann verstehen, wollen zu speichern Sie die Verbindungszeichenfolge in der Maschine.config-Datei nicht zu wiederholen, die exakt dieselbe Verbindungszeichenfolge in 25 verschiedenen web.config-Dateien. Ich würde vorschlagen, Sie jedoch, dass die meisten Menschen, die haben 25 Anwendungen auf dem gleichen server wird wahrscheinlich viele verschiedene Verbindungszeichenfolgen, weitgehend einzigartig für jede Anwendung.
    InformationsquelleAutor CraigTP
  4. 3

    Wenn Sicherheit ist das primäre Anliegen, konzentrieren Sie sich auf das sperren der Datenbank-und Benutzer-Berechtigungen. Der Sicherheits-Unterschied zwischen web/Maschine .config ist minimal. Colin ' s Antwort ist richtig. Ich würde gestimmt haben, nach oben oder kommentiert es, aber ich habe nicht die moxie noch!

    • Ja - Sicherheit ist eine vielschichtige Tier. Sie sollten Ihr bestes tun, um die Sperrung der bits unter der Oberfläche, als auch, was ist an der Oberfläche nur um sicher zu sein.
    InformationsquelleAutor Jerry
  5. 1

    Gibt es eine Menge guter Punkte, hier. JBrooks's-Umgebung ist am nächsten an mir, aber am Ende, ich Stimme mit dem setzen von Verbindungszeichenfolgen in der Maschine.config.

    Ich Stimme mit OJ aber nicht aus dem Grund, die er zitiert, hier. Ich möchte darauf hinweisen, wie JBrooks sagte, Verbindungszeichenfolgen werden sehr wahrscheinlich andere Anmeldeinformationen verwenden, die in Entwicklung und Produktion-Umgebungen. Unsere intranet-Entwicklung-Datenbanken, zum Beispiel, alle haben den gleichen Satz von einfachen Anmeldeinformationen während unserer Produktion Datenbanken haben jeweils unterschiedliche Anmeldeinformationen mit komplexen Passwörtern. Es gibt also sehr gute Gründe, die für nicht setzen Sie Ihre connection strings in der Web/App.config-Datei, sondern in eine Datei lokal auf dem Ziel-server. Ich, wie die Registrierung selbst, aber ich weiß, dass das überhaupt nicht unterstützt. Klar, die Maschine.config-Datei gibt es eine Lösung zu bieten.

    Nein, ich Stimme mit OJ, weil die Maschine.config befindet sich in der .Net framework und geändert werden kann von Microsoft. Aber Microsoft weiß nichts von der connectionStrings.config - Datei auf unserer Produktions-Server. Diese Datei wird geladen, durch die Web/App.config-Dateien mit:

    <connectionStrings configSource="path\to\connectionStrings.config"/>

    blowdart machte den Punkt über die Verschlüsselung-immer eine gute Idee. Aber am Ende, der einzige Weg, um vollständig schützen Sie Ihre Datenbank-Anmeldeinformationen ändern Sie diese regelmäßig.

    InformationsquelleAutor sthames42
  6. 0

    Sicherheit Weise kann man sich in die Speicherung Ihrer Verbindungszeichenfolgen in der eigenen verschlüsselt .config-Datei, die Ihre web.config-Datei ein Verweis auf.

    • Sie können verschlüsselt nur Teile der web.config. Sie nicht haben, um eine ganz neue Datei.
    • normalerweise finde ich es einfacher zu verwalten, wenn Sie in eine separate Datei. vor allem, wenn Sie haben eine Menge von Verbindungszeichenfolgen.
    InformationsquelleAutor MakkyNZ
  7. 0

    alle guten Punkte. In meinem Umfeld, Datenbanken geteilt werden, so dass die Speicherung in einer web.config Kräfte Redundanz. Wir verwenden standard-SQL-Datenbanken hier, dass jeder zugreift. Eine separate config-Datei wird bevorzugt. Dies ermöglicht für die Standardisierung, Sicherheit und die Beseitigung der Notwendigkeit, ändern Sie die web.config, wenn eine Anwendung bereitgestellt wird.

    InformationsquelleAutor Clem
Schreibe einen Kommentar