nicht angemeldet
XAMPP: phpMyAdmin zur mySQL Verwaltung: kein Login/Logout
Hallo Forum!
Ich habe (unter einem nicht öffentlich zugänglichen Rechner!) testweise XAMPP installiert.
Nach der erfolgreichen Installation meldete mir http://localhost/phpmyadmin/ im Browser zunächst, dass das root Passwort meiner Datenbank nicht gesetzt ist.
Dieses setzte ich mit: \xampp\mysql\bin\mysqladmin -u root password geheim
Anschließend hatte ich das Problem, dass sich die Seite http://localhost/phpmyadmin/ damit meldete, dass das Passwort nicht bekannt/korrekt sei
Nun habe ich herausgefunden, dass man das Passwort in
Datei: \xampp\phpmyadmin\config.inc.php,
Zeile: $cfg['Servers'][$i]['password'] = 'geheim';
eintragen kann. Der Connect unter http://localhost/phpmyadmin/ wird nun ohne Warnung und Fehler hergestellt, ABER:
- ist es verwunderlich, dass ich keine Passwortabfrage erhalte.
- ist es noch verwunderlicher, dass ein Logout nicht möglich ist: An der Stelle, an der laut Webrecherche der Logout Button steht (unter Importieren) steht bei mir NICHTS.
Ich vermute, dass es sich bei der derzeitigen Konfiguration um eine unsichere Konfiguration handelt. Aber was ist verkehrt, was muß ich ändern?
Viele Grüße,
Richard
-
phpMyAdmin solltest du mit einer .htaccess schützen. Das Passwort dient nur für den Zugriff auf die Datenbank.
-
setze $cfg['Servers'][$i]['auth_type'] = 'cookie';
@Tom123: selten soviel halbwissen präsentiert bekommen wie heute von dir ;)
Gruß,
Niklas-
Hi Niklas!
setze $cfg['Servers'][$i]['auth_type'] = 'cookie';
Erst mal Danke für den Tip. Aber darf ich nachfragen, was ich da eigentlich mit dieser Zeile dann bewirke?
Und auch, warum der Vorschlag von Tom123 halbwissen darstellt (mir leuchtet grundsätzlich es ein, den Zugriff auf die Administrationsseite mittels htaccess zu regeln)?Danke,
Richard-
echo $begrüßung;
setze $cfg['Servers'][$i]['auth_type'] = 'cookie';
Erst mal Danke für den Tip. Aber darf ich nachfragen, was ich da eigentlich mit dieser Zeile dann bewirke?
phpMyAdmin hat eine Dokumentation, in der alle Werte für auth_type beschrieben sind.
Und auch, warum der Vorschlag von Tom123 halbwissen darstellt (mir leuchtet grundsätzlich es ein, den Zugriff auf die Administrationsseite mittels htaccess zu regeln)?
Was bringt es dir denn beim täglichen Arbeiten, ob du nun ein Passwort für die Applikation oder ein Passwort für die Daten eingeben musst? Jedenfalls ist das kein nennenswerter Unterschied. Vom Sicherheitsstandpunkt betrachtet sieht die Sachlage anders aus. Du hast beim Web-Zugriffsschutz das Root-Passwort in der Konfigurationsdatei eingetragen (doppelte Passworteingabe wäre unpraktisch). Wenn man die Möglichkeit hat, diese Konfigurationsdatei zu lesen, kann man die Daten gleich als ungesichert betrachten. Hast du dein Root-Passwort stattdessen nur in deinem Kopf notiert und autorisierst dich über den PMA bei der Datenbank, dann musst du nur noch dafür sorgen, dass jede Anwendung ihre eigene(n) Datenbank(en) und Zugangsdaten bekommt. Ansonsten fände man ja das Root-Passwort bei denen.
Da es im Webumfeld den Zustand eingeloggt nicht gibt, simuliert man ihn gern, beispielsweise mit einem Cookie und einem Timeout. Dann würde eine "Logout"-Funktion den Keks löschen, woraufhin der nächste Zugriff ohne Zugangsdatenkeks erfolgt. Alternativ bietet sich das HTTP-eigene Zugriffsschutzverfahren an, dann aber über den PMA, nicht über das Verzeichnis in dem er liegt. Ein Logout entspricht in dem Fall dem Schließen des Browsers.
Beide Verfahren haben aber auch mindestens den einen Nachteil, dass die Zugangsdaten ständig zwischen Web-Client und -Server hin und hergesendet werden, und das unverschlüsselt, wenn du nicht gerade SSL aufgesetzt hast.
echo "$verabschiedung $name";
-
Hi dedlfix!
phpMyAdmin hat eine Dokumentation, in der alle Werte für auth_type beschrieben sind.
Ja, self ist der Mann - ich werd mal nachsehen.
Die Begründung, warum es besser ist, das Passwort beim Datenbankzugriff und nicht bei der Anwendung erforderlich zu machen, konnte ich direkt nachvollziehen - Danke für die Erklärung.
Was es mit dem Keks auf sich hat, ist mir noch nicht so ganz klar geworden - aber bevor ich weiter dumm frage, werd ich mal noch ein bissl rumprobieren/recherchieren.
Das Problem der Authentifizierung über eine unverschlüsselte Verbindung leuchtet mir hingegen wieder ein.
Also, vielen Dank für deine Erklärungen,
Richard-
Was es mit dem Keks auf sich hat, ist mir noch nicht so ganz klar geworden - aber bevor ich weiter dumm frage, werd ich mal noch ein bissl rumprobieren/recherchieren.
stichworte: cookies und sessions
-
echo $begrüßung;
Die Begründung, warum es besser ist, das Passwort beim Datenbankzugriff und nicht bei der Anwendung erforderlich zu machen, konnte ich direkt nachvollziehen - Danke für die Erklärung.
Was es mit dem Keks auf sich hat, ist mir noch nicht so ganz klar geworden - aber bevor ich weiter dumm frage, werd ich mal noch ein bissl rumprobieren/recherchieren.HTTP kennt nur Request und den dazu gehörenden Response. Dazwischen existiert normalerweise nichts, also auch keine Datenzwischenspeicherung auf dem Server. Grund ist, dass ein Client nicht eindeutig wiederzuerkennen ist. Dieses Manko versuchen diverse Mechanismen auszugleichen. HTTP selbst schickt bei jedem Request erneut die Zugangsdaten mit. Manche finden aber das Fenster zur Eingabe der Zugangsdaten nicht gut anzusehen und wollen ein Formular in der Webseite haben. Doch das arbeitet nicht mit mit der HTTP-Authentifizierung zusammen. Außerdem hab man damit zwar eine Zugangsbeschränkung aber noch keine Zwischenspeicherung von temporären Daten auf dem Server bezogen auf eine Sitzung, also mehrere Handlungen (Request+Response), die einem Ziel dienen. Mit dem Session-Mechanismus kann man beides verbinden. Statt den Zugangsdaten wird nur noch eine Session-ID in Form eines Cookies oder eines Parameters mitgesendet. Vom Sicherheitsstandpunkt betrachtet ist das jedoch keine sehr große Verbesserung. Ob nun jemand die Session-ID oder die Zugangsdaten während der Übertragung abfängt, bleibt sich gleich, mit beiden wird man als authentifiziert angesehen. Es gibt allerdings die Möglichkeit, durch einen "Logout"-Request die Session-ID ungültig zu machen, sprich die damit auf dem Server verbundenen Daten zu löschen, was zumindest eine zeitliche Einschränkung der Session-ID-Nutzbarkeit mit sich bringt. Kennung und Passwort werden aber auch bei einer Session (ohne SSL im Klartext) übertragen, wenn auch nur einmalig am Anfang. Außerdem werden die eigentlichen DBMS-Zugangsdaten oftmals in einer temporären Datei in einem für alle Applikationen auf dem Server zugänglichen Bereich abgelegt (allgemeines Temp-Verzeichnis), wenn man das nicht bewusst umkonfiguriert.
echo "$verabschiedung $name";
-
Hi dedlfix!
Generell ist das, was hier beschrieben ist, klar. Es sieht doch dann so aus, dass der Server für die session eine ID erzeugt, sie sich "merkt" und an den Client sendet. Für jede Anfrage des Client ist von diesem im Folgenden die SessionID mitzusenden.
Wird der logout betätigt, wird die Session ID auf dem Server "vergessen".Jetzt die konkreten Fragen:
Da es im Webumfeld den Zustand eingeloggt nicht gibt, simuliert man ihn gern, beispielsweise mit einem Cookie und einem Timeout. Dann würde eine "Logout"-Funktion den Keks löschen, woraufhin der nächste Zugriff ohne Zugangsdatenkeks erfolgt.
Verstehe ich richtig, dass das Cookie nichts anderes ist, als eine Clientseitige "Krücke" um zu vermeiden, dass bei jeder Serverantwort die SessionId als Input Parameter in weitere Anfragen vorcodiert werden muß, sondern stattdessen Clientseitig aus dem Coockie wieder gelesen werden kann? Dann fände ich die Technik ohne Cookie aber vorteilhafter, also dass Server und Client mit der SessionID "Ping Pong" spielen.
Alternativ bietet sich das HTTP-eigene Zugriffsschutzverfahren an, dann aber über den PMA, nicht über das Verzeichnis in dem er liegt. Ein Logout entspricht in dem Fall dem Schließen des Browsers.
Hier hakt es ein bischen: das HTTP-eigene Zugriffsschutzverfahren: hierunter würde ich verstehen, ein Verzeichnis mittels .htaccess zu schützen. Wie soll ich denn das nun über den PMA machen?
Danke für die bisherigen Erklärungen,
Richard-
echo $begrüßung;
Verstehe ich richtig, dass das Cookie nichts anderes ist, als eine Clientseitige "Krücke" um zu vermeiden, dass bei jeder Serverantwort die SessionId als Input Parameter in weitere Anfragen vorcodiert werden muß, sondern stattdessen Clientseitig aus dem Coockie wieder gelesen werden kann? Dann fände ich die Technik ohne Cookie aber vorteilhafter, also dass Server und Client mit der SessionID "Ping Pong" spielen.
Der einzige Vorteil, den ich darin sehe ist, dass die Ping-Pong-Variante auch bei nicht akzeptierten Cookies funktioniert. Doch das Zulassen sollte bei einem Arbeiten mit dem PMA das kleinste Problem sein, noch dazu wenn der PMA in einer geschützten Umgebung läuft (sprich bei dir im Kämmerlein, nicht Schutz im Sinne von ".htaccess").
Alternativ bietet sich das HTTP-eigene Zugriffsschutzverfahren an, dann aber über den PMA, nicht über das Verzeichnis in dem er liegt. Ein Logout entspricht in dem Fall dem Schließen des Browsers.
Hier hakt es ein bischen: das HTTP-eigene Zugriffsschutzverfahren: hierunter würde ich verstehen, ein Verzeichnis mittels .htaccess zu schützen.Ja, üblicherweise wird HTTP-Authentifizierung auch gern als .htaccess-Zugriffsschutz bezeichnet, weil das eine gängige Methode ist, dieses Feature mit dem Apachen zu realisieren. Andere Systemem kennen keine .htaccess, sehr wohl aber HTTP-Authentifizierung.
Wie soll ich denn das nun über den PMA machen?
Damit komme ich wieder zu meiner ersten Aussage in diesem Faden: Siehe Dokumentation zu $cfg['Servers'][$i]['auth_type']
Da ist übrigens auch ein schönes Beispiel für HTTP-Authentifizierung, die auch unterm Apachen nicht über .htaccess realisiert ist.
echo "$verabschiedung $name";
-
Hi dedlfix!
Wie soll ich denn das nun über den PMA machen?
Damit komme ich wieder zu meiner ersten Aussage in diesem Faden: Siehe Dokumentation zu $cfg['Servers'][$i]['auth_type']
Da ist übrigens auch ein schönes Beispiel für HTTP-Authentifizierung, die auch unterm Apachen nicht über .htaccess realisiert ist.
Was lange wärt, wird endlich gut - jetzt versteh ich, was da gemacht wird - vielen, vielen Dank für deine Geduld.
Grüße,
Richard
-
-
-
-
-
-
-