✔ Sicherer Datenbank Zugriff?

D

dartox

Erfahrenes Mitglied
Hallo.
Und zwar habe ich mir selbst zu Übungszwecken einen Blog geschrieben, mit relationalen Datenbanken etc.

Jetzt habe ich natürlich auch eine connect.php Datei, die ich überall include wo der Datenbankzugriff benötigt wird.

Jetzt frage ich mich aber wenn ich irgendwann mal diese Dateine auf den Webhoster stelle, so kann ja jeder meine connect.php ansurfen und im Klartext sehen welche DB und vorallem welches Passwort ich habe!!

In der connect.php steht ja mein Nutzername und Passwort drinnen.

Jetzt möcht ich fragen wie das wirklich funktioniert? Weil ein Passwort wird ja immer benötigt?!

Danke. Grusss dartox
 
PHP-Scripts werden durch den Webserver interpretiert, der Sourcecode des PHP-Scripts geht nicht an den Browser. Damit ist deine Befürchtung erstmal hinfällig.

Du kannst jedoch prüfen, ob ein direkter Zugriff auf die connect.php durchgeführt wird und ggf. zu einer anderen Datei umleiten. Dazu prüfst du, welche Datei in $_SERVER['PHP_SELF'] hinterlegt ist, also ob es sich um die connect.php handelt und leitest mit header('Location: ...') auf eine andere Datei um.

Aber wie gesagt, eigentlich musst du dir darum keinen Kopf machen, denn PHP-Code wird im Browser nicht sichtbar sein, wenn der Webserver das PHP-Modul geladen und .php-Dateien mit dem Typ application/x-httpd-php verknüpft ist.
 
Wie der Saftmeister schon gesagt hat, können PHP Scripte vom Browser nicht ausgelesen werden. Sollte aber mal auf dem Server das PHP Modul ausfallen, wäre das meines Wissens nach schon möglich.
Es gibt aber zwei Möglichkeit, eine Datei vor dem externen Zugriff zu bewahren. Wenn von der Struktur her möglich, kannst du die Datei in einem Verzeichnis außerhalb des Root Verzeichnisses ablegen. Sollte das z.B. "httpdocs" heißen, und das "cgi-bin" Verzeichnis liegt parallel dazu, könntest du kritische Dateien dort ablegen. PHP kann problemlos darauf zugreifen, von außen ist der Weg absolut dicht.
Wenn das nicht möglich ist, bleibt noch der Weg, die Datei in einem extra Verzeichnis abzulegen und das mit einem htaccess Schutz zu versehen. Da ja niemand darauf zugreifen muß, kannst du ein beliebig wirres Login und Passwort eintragen, oder, wenn du über die Serversteuerung Zugriff auf die Seitenverwaltung hast, gar keine Zugangsdaten eintragen. Auch dann ist die Datei absolut sicher.
 
Du kannst auch .htaccess verwenden, um den Zugriff auf die Datei zu verweigern, völlig ohne Passwort:

Code: 
<Files connect.php>
Order deny,allow
Deny from all
</Files>

Ungetestet.
 
Danke. Klingt einläuchtend.

Ich hätte noch eine Grundverständnis Frage.

Und zwar ist es ja wichtig mit relationalen Datenbanken zu Arbeiten um doppelte Einträge etc. zu vermeiden.

Ich habe mit mit nem visuellen DB Designer eben solche vernundenen DBs erstellt. Der hat mir ganz einfach in meine KommentareDB eine Spalte namens artikel_id eingefügt, so dass hier die IDs der Artikel stehen die den Kommentaren zugeordnet sind.

Aber ich muss jetzt im Endeffekt sowieso wieder per insert händisch die Artikel_IDs einfügen (in die KommentarDB), damit das korrekt funkioniert. Mir erschliesst sich also nicht ganz der Sinn der Sache, wenn das nicht automatisch eingefügt wird und so wieder der selbe Wert (z.B. Artikel_ID 61) öfters in der DB steht (weils ja mehrere Kommetare gibt)?!
 
Hmm, was meinst du mit händisch? Du kannst im PHP-Script durchaus mehrere SQL-Queries nacheinander ausführen. Normalerweise macht man es so:

- Man baut ein Formular, in dem man Kommentare zu einem Artikel schreiben kann.
- Das Formular hat eine Action, in der ein PHP-Script als Adresse und evtl. noch GET-Parameter für die Artikel-ID zum Speichern des Kommentars hinterlegt sind.
- Im PHP-Script, was den Kommentar speichert, wird die Artikel-ID aus den GET-Parametern geholt und zusammen mit den Kommentardaten wie Subject, User, Text, Email und ähnliches in der Tabelle für Kommentare abgelegt.

Das die ID des zum Kommentar zugehörigen Artikel dann zusammen mit den anderen "Nutzdaten" mit gespeichert wird, ist völlig klar, denn es muss ja ein Bezug hergestellt werden. Das die ID dann mehrfach vorkommt ist auch korrekt und entspricht der zweiten bzw. dritten Normalform. Man könnte sogar soweit gehen, das Artikel in einer Tabelle ("artikel") stehen, Kommentare in einer anderen stehen ("kommentare") und es eine dritte Tabelle "kommentare_zu_artikel", in der nur die IDs der Kommentare den IDs der Artikel zugeordnet werden.

Was würdest du denn sonst als Referenz verwenden, um den Bezug zwischen Artikel und Kommentar herzustellen?
 
Genau so hab ich es auch. Also ist ja eh logisch das man das verknüpfen muss, nur heisst es ja immer "doppelte DB Einträge unbedingt vermeiden". Aber logisch gesehen wird es immer doppelte Einträge geben (auch mit ner DB artikel_kommentare wo nur 2 ID Spalten sind).

Schlussendlich könnte ich theoretisch auch nur eine artikelDB erstellen, in der 3 Spalten sind (ID, Artikeltext und Kommentartext) und alle kommentare da einfügen (dann sind bei 3 Kommentaren auch 3 Spalten die den selben Artikeltext besitzen). Aber im Grunde ist es ja nichts anderes als wenn ich da auf die artikel_kommentareDB Verweise und dort die ID des Artikels 3 Mal aufgeführt wird. Verstehst du ungefähr was ich meine?

Klar, die 2. Variante ist natürlich schöner, aber ich dachte Anfangs das die Verweise eben nur Verweise sind (Referenzen) und so keinen Speicherplatz brauchen, aber so ist es ja nicht.

PS: Mit händisch meinte ich wie du sagst einfach nen zusätzlichen query ausführen.
 
Zuletzt bearbeitet:
Mit Redundanzen vermeiden ist gemeint, das man keine Nutzdaten doppelt speichern soll. Alles was an Nutzdaten doppelt gespeichert werden müsste, kann man über Referenz-Tabellen in eine 1:n-Beziehung überführen. Les dir mal die Normalisierungsformen bei dem Link durch. Im Regelfall wirst du bis zur dritten Normalform kommen, und das ist in den meisten Fällen auch ausreichend.
 
Danke. Das mit den Normalformen verstehe ich. Aber grundsätzlich lässt sich sagen "Redundanzen: Nein, ausser bei IDs!" ?!
 
Eine ID ist ein (Primär-)Schlüssel. Da dieser nicht als Attribut eines Tupels angesehen wird, darf dieser durchaus redundant vorkommen. Sonst würde das Prinzip "Fremdschlüssel" ja völlig ad-absurdum geführt ;-)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück