logintest aus subdir, ggf. ins loginform schicken per header()?
jobo
- php
Hallo,
bei einem simplen kundenlogin (kein datengeschützter bereich in dem sinne) kommt man dann per link auch in unterverzeichnisse. example.com/zeigwas.php included das login_script.php und das spuckt das login_form.php aus, wenn nötig. in zeigwas.php gibt es links auf zeigmehr/nochmehr.php. in nochmehr.php kann ich das login_script.php nicht mehr includen, weil dann die relativen pfadangaben nicht stimmen. ich könnte ja (ausnahmsweise) den relevanten teil des loginscriptes dorthin kopieren und dann per
header('Location: http://example.com/zeigwas.php/');
eine ebene höher gehen, denn auf zeigmehr/nochmehr.php soll man eigentlich nur über zeigwas.php kommen. in zeigmehr/nochmehr.php gibts eben die möglichkeit, eine formmailer zu nutzen, den möchte ich eventuellen spambots nicht zugänglich machen, was durch das loginscript ja verhindert würde.
oder hat die idee mit dem header einen haken?
Gruß
jobo
Hallo jobo,
was passiert, wenn man zeigmehr/nochmehr.php direkt aufruft?
Generell besteht die Möglichkeit, per htaccess und htpasswd Ordner zu schützen. Diesen Mechanismus kann man auch mittels php dynamisch nutzen, indem man dem Browser sendet, dass es sich um eine passwortgeschütze Siete handelt.
Erst nachdem der User sich angemeldet hat, erscheint die Abfrage nicht mehr. Bei einem erfolgreichem Login sind bestimmte Variablen innerhalb PHPs gesetzt soweit ich mich erinnere. Leider finde ich grade kein Beispiel dazu :-(
Eine Alternative wäre es, über Sessions zu prüfen, ob man eingeloggt ist oder nicht. Wenn nein, dann Login-Maske und diese Routine muss in jedes zu schützendes PHP.
Gruß,
the-FoX
Hallo,
Hallo jobo,
was passiert, wenn man zeigmehr/nochmehr.php direkt aufruft?
Ja eben, momentan ist sie aufrufbar, wenn auch nur innerhalb der Session-login-geschützten Seite.
Generell besteht die Möglichkeit, per htaccess und htpasswd Ordner zu schützen. Diesen Mechanismus kann man auch mittels php dynamisch nutzen, indem man dem Browser sendet, dass es sich um eine passwortgeschütze Siete handelt.
Ja, aber das kommt hier nicht in Frage, weil nicht Nutzer _und_ Passwort angegeben werden soll.
Eine Alternative wäre es, über Sessions zu prüfen, ob man eingeloggt ist oder nicht. Wenn nein, dann Login-Maske und diese Routine muss in jedes zu schützendes PHP.
Genau so läuft es, weil ich aber in einem unterordner bin, müsste ich die relativen Pfade anpassen, dass es für den Unterordner geht genau wie für den drüberliegenden. So dachte ich das mit dem Header("Location:") wäre vielleicht das Praktikabelste, zumal wie gesagt auf diese Seite sowieso nur "böswillige" kommen könnten, denn die User kommen an die Links zum Formmailer auch jetzt schon nur über die Session-login-page.
Gruß
jobo
Hi,
was passiert, wenn man zeigmehr/nochmehr.php direkt aufruft?
Ja eben, momentan ist sie aufrufbar, wenn auch nur innerhalb der Session-login-geschützten Seite.
D.h., zeigmehr/nochmehr.php selbst ist vor Aufrufen geschützt, Ja oder Nein?
Deine Beschreibung klang bisher mehr nach nein.
Eine Alternative wäre es, über Sessions zu prüfen, ob man eingeloggt ist oder nicht. Wenn nein, dann Login-Maske und diese Routine muss in jedes zu schützendes PHP.
Genau so läuft es,
Wo ist dann das Problem?
weil ich aber in einem unterordner bin, müsste ich die relativen Pfade anpassen, dass es für den Unterordner geht genau wie für den drüberliegenden.
Nein, musst du natürlich nicht.
Includen von Dateien geht bspw. auch in Bezug auf DOCUMENT_ROOT.
So dachte ich das mit dem Header("Location:") wäre vielleicht das Praktikabelste, zumal wie gesagt auf diese Seite sowieso nur "böswillige" kommen könnten, denn die User kommen an die Links zum Formmailer auch jetzt schon nur über die Session-login-page.
Was heisst, sie "kommen an die Links"?
Wenn der einzige "Schutz" darin besteht, dass die Adresse vermeintlich nicht bekannt ist, dann besteht also momentan *gar* *kein* Schutz.
MfG ChrisB
was passiert, wenn man zeigmehr/nochmehr.php direkt aufruft?
Ja eben, momentan ist sie aufrufbar, wenn auch nur innerhalb der Session-login-geschützten Seite.D.h., zeigmehr/nochmehr.php selbst ist vor Aufrufen geschützt, Ja oder Nein?
Nein.
Eine Alternative wäre es, über Sessions zu prüfen, ob man eingeloggt ist oder nicht. Wenn nein, dann Login-Maske und diese Routine muss in jedes zu schützendes PHP.
Genau so läuft es,
In dem übergeordneten Verzeichnis zeigwas.php (wenn logged in).
Wo ist dann das Problem?
weil ich aber in einem unterordner bin, müsste ich die relativen Pfade anpassen, dass es für den Unterordner geht genau wie für den drüberliegenden.
Nein, musst du natürlich nicht.
Includen von Dateien geht bspw. auch in Bezug auf DOCUMENT_ROOT.
Ja, dann bin ich aber im zeigmehr-Verzeichnis. Müsste ich den link bzw. das action-attribut im Loginscript auf /zeigwas.php (mit starting slash) definieren, statt auf zeigwas.php, weil es ja im directory zeigmehr/ keine zeigwas.php gibt. Das wäre eine Lösung.
So dachte ich das mit dem Header("Location:") wäre vielleicht das Praktikabelste, zumal wie gesagt auf diese Seite sowieso nur "böswillige" kommen könnten, denn die User kommen an die Links zum Formmailer auch jetzt schon nur über die Session-login-page.
Was heisst, sie "kommen an die Links"?
Wenn der einzige "Schutz" darin besteht, dass die Adresse vermeintlich nicht bekannt ist, dann besteht also momentan *gar* *kein* Schutz.
Genau.
Hi,
Includen von Dateien geht bspw. auch in Bezug auf DOCUMENT_ROOT.
Ja, dann bin ich aber im zeigmehr-Verzeichnis.
Aus deiner Beschreibung war nicht so ersichtlich, ob du von server- oder clientseitigen Pfaden sprachst.
Müsste ich den link bzw. das action-attribut im Loginscript auf /zeigwas.php (mit starting slash) definieren, statt auf zeigwas.php, weil es ja im directory zeigmehr/ keine zeigwas.php gibt. Das wäre eine Lösung.
Oder aber, du blendest das Login-Formular *in* dem Dokument ein, das der Nutzer gerade angefordert hat, zu dessen Abruf er aber ohne vorherige Authenifizierung gar nicht berechtigt sein soll.
Dann kommst du auch sehr problemlos wieder an die gleiche Stelle zurück, nachdem er sich eingeloggt hat.
MfG ChrisB
Oder aber, du blendest das Login-Formular *in* dem Dokument ein, das der Nutzer gerade angefordert hat, zu dessen Abruf er aber ohne vorherige Authenifizierung gar nicht berechtigt sein soll.
Dann kommst du auch sehr problemlos wieder an die gleiche Stelle zurück, nachdem er sich eingeloggt hat.
ja, "aber" dann geht auf woanders/zeigwasanderes.php mit include("../login_check.php") zweimal ins leere. denn login_check.php included "login_form.php", das müsste dann ergänzt werden um $_SERVER["PHP_SELF"] . PATH_SEPARATOR . "login_form.php" und in login_form.php ist action="zeigwas.php", das wäre dann wohl action="/zeigwas.php" denn der leading-slash sollte wohl andeuten, dass dann nicht example.com/woanader/zeigwas.php angefragt wird (die gibt es ja auch nciht) sondern example.com/zeigwas.php.
Hi,
ja, "aber" dann geht auf woanders/zeigwasanderes.php mit include("../login_check.php") zweimal ins leere.
Deswegen erwähnte ich ja gerade eben DOCUMENT_ROOT.
denn login_check.php included "login_form.php", das müsste dann ergänzt werden um $_SERVER["PHP_SELF"] . PATH_SEPARATOR . "login_form.php"
Da muss nicht "ergänzt" werden, sondern da ist das nötige bereits vorhanden, weil wir ja vorher nachgedacht haben ...
und in login_form.php ist action="zeigwas.php"
Auch der Inhalt des action-Attributes lässt sich sehr bequem dynamisch entsprechend der jeweiligen Gegebenheit setzen.
MfG ChrisB
Auch der Inhalt des action-Attributes lässt sich sehr bequem dynamisch entsprechend der jeweiligen Gegebenheit setzen.
Naja, der Slash am Anfang würde es ja bringen.
Hi,
Auch der Inhalt des action-Attributes lässt sich sehr bequem dynamisch entsprechend der jeweiligen Gegebenheit setzen.
Naja, der Slash am Anfang würde es ja bringen.
Nur, wenn du unbedingt auf eine andere Seite umleiten willst - Notwendigkeit dazu sehe ich aber keine.
Nutzer fordert /blah/blubb an, darf die Inhalte nicht sehen, weil nicht eingeloggt.
Loginformular wird innerhalb dieses Dokumentes angezeigt, action zeigt wieder auf /blah/blubb.
Übermittelte Login-Daten werden geprüft - wenn korrekt wird der gewünschte Inhalt von /blah/blubb angezeigt; wenn nicht, dann entsprechende Meldung, und wiederum Login-Formular.
Den Nutzer zum Login immer auf eine feste Adresse zu verweisen, halte ich für eine Unsitte, die heutzutage eigentlich nicht mehr nötig sein sollte.
MfG ChrisB
Nutzer fordert /blah/blubb an, darf die Inhalte nicht sehen, weil nicht eingeloggt.
Loginformular wird innerhalb dieses Dokumentes angezeigt, action zeigt wieder auf /blah/blubb.
Übermittelte Login-Daten werden geprüft - wenn korrekt wird der gewünschte Inhalt von /blah/blubb angezeigt; wenn nicht, dann entsprechende Meldung, und wiederum Login-Formular.Den Nutzer zum Login immer auf eine feste Adresse zu verweisen, halte ich für eine Unsitte, die heutzutage eigentlich nicht mehr nötig sein sollte.
Auch wieder war, so sehe ich es ja auch, aber auf diese Unterseite kommt man eigentlich eben garnicht direkt. Und ich müsste am Formular rumfummeln. Aber so wie dus sagst ists eigentlich state-of-the-art