nicht angemeldet
Hallo Sven!
Re-Moin!
:)
Ruf deine Include-Datei (deren Lage auf dem Server, also auch deren URL du ja kennst) einfach im Browser auf. Das, was du da siehst, wird jeder andere auch sehen.
Nix, das ist schön :)
...dann werden diese Funktionen in der include-Datei ja niemals aufgerufen und also auch nicht ausgeführt -> kein Output. Wenn der Server aber aufgrund der Dateiendung meint, die Datei nicht durch den PHP-Parser schicken zu müssen, sondern sie im Klartext ausliefern zu müssen, dann ist das schlecht. Deshalb: Dateiendung .php geht auf Nummer Sicher. Manche Provider lassen auch .inc mit PHP parsen, weil das eine beliebte Endung von vielen PHP-Programmierern ist, aber darauf ist kein Verlaß.
Ach jetzt verstehe ich, (bei den Österreichern dauerts ab und zu ein bisserl länger vor allem um die nachtschlafende Zeit ...). Dann würde mein lieber Besucher also meinen PHP-Code sehen ...
Wenn irgendein Skript "echo $passwort" macht, und das zum Browser gelangt, wäre es blöd. Was aber keine Ausgabe produziert, wird von PHP ja nicht an die Außenwelt geliefert. Deshalb ist es ja so wichtig, daß die Include-Dateien (meist mit sensitiven Konfigurationsdaten) nicht ungeparst an den Browser gesendet werden. Wenn PHP zum Zuge kommt, sind im Browser keine PHP-Anweisungen mehr zu sehen. :)
Ich denk jetzt hab ichs. Juhu - ein Erfolgserlebnis um diese Zeit, das ist schön.
Und die Authentifizierung sollte dann wahrscheinlich wieder über SSL abgewickelt und das Passwort mit MD5 verschlüsselt werden, oder?
Wenn du SSL benutzen kannst, ist alles relativ einfach. Du hast als URL eben nicht mehr http://, sondern https://, und damit mußt du dich vermutlich nur bei einem einzigen Link auf deiner Webseite rumplagen, nämlich auf der Startseite von http://deinedomain/. Von dortaus geht der Link zur Startseite auf https://deinedomain/ (die konkrete Lösung ist etwas abhängig davon, wie dein Provider das alles gelöst hat, ob du z.B. ein eigenes Verzeichnis für den https-Server kriegst, oder ob die Seiten unter beiden Protokollen erreichbar sind (was ich für schlecht halten würde, weil User dann auch unverschlüsselt die Funktionen nutzen könnten).
Ich hatte eigentlich gedacht, dass die sichere Verbindung nur genutzt werden "sollte" bei sensitiven Daten also z.B. Bestellung. Mir ist schon klar, dass ich es bei den anderen Seiten auch nutzen kann, habe aber heute bei drweb gelesen, dass die Verbindung mit SSL sehr langsam ist, ist da was dran?
» Unzertifizierte Schlüssel lassen beim Betreten im Browser ein Dialogfenster aufgehen, in dem der Benutzer zur Bestätigung aufgefordert wird, daß er wirklich mit diesem Server arbeiten möchte. Solche "Eigenzertifikate" beweisen im Prinzip garnichts, aber immerhin ist die Verbindung verschlüsselt. Der Surfer ist eben nicht 100% sicher, daß die Gegenseite wirklich _DIE_ Gegenseite ist, die er meint vor sich zu haben. Kann bei Bankgeschäften durchaus sehr interessant sein, wenn man sich (durch Tippfehler) nicht mit dem echten Bankserver verbindet.
» Eine solche SSL-Dialogbox erscheint zum Beispiel hier: https://www.ccc.de.
web.de Freemail macht es übrigens genauso:
Ich weiß nicht, irgendwie sieht das nicht gerade einladend und vertrauenserweckend aus, wenn man auf so eine Seite ohne zertifizierten Schlüssel einsteigt. Ich denke mir, dass Surfer mit wenig Erfahrung im Internet von solchen Meldungen eher abgeschreckt werden, als wenn man gar keine sichere Verbindung via SSL verwendet.
Danke nochmals für die Hilfe, jetzt ist mir einiges klarer geworden.
Tschüss
Sabine
- Sven Rautenberg