PHP Weiterleitung nach "DB-Check"

[Physically]

Guten Abend,

ich habe ein Formular, das z.B. index.php heißt. Dort sind ein paar Inputs drin (Name, Username, E-Mail etc.). Außerdem beinhaltet das Formular einen Submit-Button zum absenden des Formulares. Nach drücken des Buttons wird man auf register.php weitergeleitet, wo der Code checkt ob alles Felder ausgefüllt wurden, es wird Verbindung zur DB aufgenommen, und es werden die Daten in dem Formular in die DB eingetragen.

Jetzt möchte ich, dass man auf die Member-Seite weitergeleitet wird, nach dem Registrieren, wie ist das zu realisieren?

Gruß

 

[Daaron]

Sinngemäß: "Wenn Kombination aus Username und Passwort-Hash in Datenbank, setze ne Session-Variable auf "eingeloggt" und leiter weiter zu member.php".

Bei all dem Kram:
- denk an Schutz vor SQL Injections
- denk an Datenschutz: Passwörter haben weder im Klartext noch als ungesalzene Hashes was in der DB verloren

 

[Yuuri]

https://www.google.com/search?hl=en&safe=off&client=firefox-a&hs=fzJ&rls=org.mozilla:de:official&q=

+Weiterleitung&btnG=Search&oq=&aq=&aqi=&aql=&gs_sm=&gs_upl=

 

[Physically]

Ok danke, und wie setze ich die Weiterleitung auf member.php?

 

[Hancock]

http://www.faqs.org/docs/htmltut/document/index_tagsupp_4.html
=>

<meta HTTP-EQUIV="Refresh" CONTENT="5; URL=member.php">

 

[mvBarracuda]

Siehe:
http://www.schmager.de/redirect.shtml

 

[Daaron]

Ähm... NEIN!
Meta Refresh ist für REFRESH gedacht, nicht für Weiterleitungen.

Versuchs noch einmal, diesmal googlest du nach den Stichworten "php redirect" und wenn das nicht hilft, nach "php header redirect".

 

[mambokurt]

Jetzt möchte ich, dass man auf die Member-Seite weitergeleitet wird, nach dem Registrieren, wie ist das zu realisieren?

Auf _keinen_ Fall indem du redirects oder header oder so einen Müll benutzt. Das ist einfach nur worst case, einen header würde ich nichtmal mehr benutzen wenn mir einer eine Knarre an den Kopf hält ;D

Vielmehr solltest du dir mal überlegen, dein Zeug etwas aufzuräumen: du baust schlicht und ergreifend _eine_ index.php, die erledigt alle weiteren Aufrufe. Dazu gibst du einfach all deinen HTML Formularen eine <input type="hidden" name="action" value="aktuelleAktion" /> mit und fragst die dann entsprechend ab.

Beispiel:


index.php:

class index{
public function __construct() { //__construct wird beim instantiieren einer Klasse immer ausgeführt

include('./login.class.php');
$oLogin = new login(); //in der Klasse login guckst du ob der User eingelogged ist, wenn nicht gibst du das login formular aus und machst ein exit
if(isset($_POST['action'])) {
  switch($_POST['action']) {
    case 'geheimnisvollerEintrag1':
      include(./klasse1.class.php);
      $oKlasse1 = new klasse1();
    break;
    case usw
    .
    .
    .
    default:
     echo 'keine Action im Formular!';
    break;
  }
} else {
  //hier kannst du eine Standardaktion ausführen, Startseite anzeigen oder sowas
  include(./start.class.php);
  $oStart = new start();
}

}

}
$index = new index();

 

[Daaron]

Auf _keinen_ Fall indem du redirects oder header oder so einen Müll benutzt. Das ist einfach nur worst case, einen header würde ich nichtmal mehr benutzen wenn mir einer eine Knarre an den Kopf hält ;D

Es gibt mehr als genug Anwendungssituationen, wo man nicht an Redirect via PHP Header Location herum kommt (wenn man PHP verwendet). Ein Beispiel wäre z.B. die Weiterleitung zu Zahlungsschnittstellen wie Paypal oder Sofortüberweisung.

 

[Yuuri]

Auf _keinen_ Fall indem du redirects oder header oder so einen Müll benutzt. Das ist einfach nur worst case, einen header würde ich nichtmal mehr benutzen wenn mir einer eine Knarre an den Kopf hält ;D

Sorry, aber das ist der größte Blödsinn, den ich seit Langem gelesen habe.

Drück mal F5 nach dem Absenden eines Formulars und du wirst evtl. Wunder erleben. Schön, wenn aufgrund eines Fehlers die Bestellbestätigungsseite doppelt aufgerufen wird und die Bestellung doppelt ausgeführt wurde. Am Liebsten noch bei einem TV für 1.500 €.

Genau aus solchen Gründen werden Redirects durchgeführt, damit POST und GET "normalisiert" werden und nichts Entscheidendes mehr enthalten, dass zu evtl. Fehlfunktionen führen kann. Dabei kannst du nun F5 auf der Seite drücken wie du lustig bist und es wird trotzdem nur eine Bestellung ausgelöst, da eben bspw. POST leer ist.

 

[mambokurt]

Vielleicht noch beispielhaft eine login.class.php:

class login{
public function __construct() {
 if(!$this->checkLogin()) {
   $this->displayLoginForm();
  } else {
    return;
  }
}

protected function displayLoginForm() {
 //hier gibst du dein loginformular aus.
}

protected function checkLogin() {
 //hier prüfst du ab ob eine session existiert, wenn ja return true
.
.
.
 if(isset($_POST['pass'], $_POST['login'])){ //das kommt aus dem loginform
 //hier prüfst du normal Passwort & Login gegen die Datenbank ab
 //wenn vorhanden return true
 //wenn nicht return false 
}
return false;
}

}

Ergänzung (11. September 2012)

Sorry, aber das ist der größte Blödsinn, den ich seit Langem gelesen habe.

Drück mal F5 nach dem Absenden eines Formulars und du wirst evtl. Wunder erleben. Schön, wenn aufgrund eines Fehlers die Bestellbestätigungsseite doppelt aufgerufen wird und die Bestellung doppelt ausgeführt wurde. Am Liebsten noch bei einem TV für 1.500 €.

Das ist trotzdem nichts was ich jemandem beibringe, der gerade PHP lernt -.- Wenn er mal so eine Situation hat kann er das googlen und wenn es wirklich keine andere Möglichkeit gibt wegen mir auch benutzen, aber jemanden auf header zu verweisen für einen login halte ich mit Verlaub für ausgemachten Bulsh -.-
Davon ab ist dieses mehrfache Anlegen bei Seitenrefresh mit headern zwar zu umgehen, lässt sich aber auch anders bewältigen. Schieb den Warenkorb in die Session und lösch ihn nach erfolgreicher Bestellung, schon kann dein User F5 drücken wie er will. Und er sieht sogar noch die beim Bestellen aufgetretenen Fehler, statt dass diese einfach weggeheadert werden wie es leider zu oft passiert. Je länger ich PHP entwickle umso weiter bin ich weg davon gelangt irgendwelche Daten durch die Ausgabe zu schleifen und wieder an den Server zu senden. Lieber habe ich meine Daten in der Session oder der DB liegen und manipuliere sie dann je nach Aufruf.

Es gibt mehr als genug Anwendungssituationen, wo man nicht an Redirect via PHP Header Location herum kommt (wenn man PHP verwendet). Ein Beispiel wäre z.B. die Weiterleitung zu Zahlungsschnittstellen wie Paypal oder Sofortüberweisung.

Das ist für mich ein Sprung aus der Anwendung, da kann von mir aus geheadert werden. Innerhalb meiner Anwendung aber nicht. ;D

 

[Yuuri]

Das ist trotzdem nichts was ich jemandem beibringe, der gerade PHP lernt -.-

Doch, genau dort setzt man an und zeigt es einem Anfänger richtig, sonst macht er den schlechten Stil evtl. noch Jahrzehnte lang. Es bringt einem Neuling überhaupt nichts, sich durch Tutorials zu wälzen, die bestimmt zu 95 % Mist sind. Vielleicht mag er es können, ihm wird aber überhaupt nicht aufgezeigt, was für Sicherheitslücken er dort evtl. einreißt, ihm werden keine Hintergründe genannt und für ein ordentliches Script reicht es vorn und hinten nicht. Kein Wunder warum PHP immer seinen schlechten Ruf beibehalten wird, wenn zu 90 % wirklich nur gefrickelt wird.

aber jemanden auf header zu verweisen für einen login halte ich mit Verlaub für ausgemachten Bulsh -.-

Aus welchem Grund? Was ist wenn der Login fehlerhaft ist? Willst du dann hunderte Session-Variablen, Post- und Get-Parameter weiterleiten? Warum lenkst du ihn nicht einfach auf die Seite /Login/Fehler um und zeigst ihm die gleiche Seite, allerdings mit Fehlermeldung und er kann somit einen erneuten Versuch wagen. Ein index.php?page=login&action=submit sieht zudem nicht wirklich schön aus.

Schieb den Warenkorb in die Session und lösch ihn nach erfolgreicher Bestellung, schon kann dein User F5 drücken wie er will.

Es war ja nur ein Beispiel. Du könntest Bestellung auch durch irgendwas anderes ersetzen, bspw. durch einen Eintrag im News-System. Plötzlich hast du zwei Einträge drin, die du leicht hättest verhindern können.

Und er sieht sogar noch die beim Bestellen aufgetretenen Fehler, statt dass diese einfach weggeheadert werden wie es leider zu oft passiert.

Und was will ein User mit Fehlermeldungen? Der User soll von Fehlermeldungen überhaupt rein gar nichts mitbekommen, sondern er soll verstehen was passiert. Ein Notice: Undefined index: xy schürt nur für Verwirrung, ggf. macht er erneut die gleiche Bestellung, weil er der Annahme ist, dass die Bestellung nicht akzeptiert wurde.

Je länger ich PHP entwickle umso weiter bin ich weg davon gelangt irgendwelche Daten durch die Ausgabe zu schleifen und wieder an den Server zu senden. Lieber habe ich meine Daten in der Session oder der DB liegen und manipuliere sie dann je nach Aufruf.

Was hat das aber mit obigem Problem zu tun? Du leitest ihn doch nur auf eine URL weiter, was dahinter steckt und was wie gemacht wird entscheidest du, der Aufruf sieht nur gescheit und durchdacht aus.

Eine 404 Error Seite wäre auch ein gutes Beispiel. Anstatt index.php?a=b&c=d&e=f in der URL stehen zu haben und die Fehlerseite zu präsentieren, kann man den User ganz elegant auf /404, /Beitrag-nicht-gefunden o.ä. weiterleiten, sodass er sofort an der URL sieht, was das Problem ist.

 

[mambokurt]

Aus welchem Grund? Was ist wenn der Login fehlerhaft ist?

Dann zeige ich das Loginform erneut an und mache ein exit(); ?

Willst du dann hunderte Session-Variablen, Post- und Get-Parameter weiterleiten? Warum lenkst du ihn nicht einfach auf die Seite /Login/Fehler um und zeigst ihm die gleiche Seite, allerdings mit Fehlermeldung und er kann somit einen erneuten Versuch wagen. Ein index.php?page=login&action=submit sieht zudem nicht wirklich schön aus.

Warum sollte ich irgendwelche Postvariablen weiterleiten? Erstmal sind das globale Arrays, und dann macht es bei einem misglückten Login wohl kaum Sinn die falschen Logindaten zu behalten? ^^ Und wir reden hier von POST Variablen, über get schicke ich maximal die SessionId oder halt hrefs.

Es war ja nur ein Beispiel. Du könntest Bestellung auch durch irgendwas anderes ersetzen, bspw. durch einen Eintrag im News-System. Plötzlich hast du zwei Einträge drin, die du leicht hättest verhindern können.

Ich glaube das ist eher eine Glaubensfrage als alles andere. Manche benutzen GOTO, manche nicht. Ich für meinen Teil habe mich schonmal durch 4 voneinander abgeleiteten Klassen mit jeweils mehr als 1000 Zeilen gewühlt auf der Suche nach einem Fehler, der nicht angezeigt wurde, weil wild geheadert wurde. Wenn du da nicht einen eigenen errorHandler aufsetzt der direkt bei Fehlern aussteigt hast du quasi keine Chance das zeitnah zu fixen.
Header sind für mich die GOTOs des 21. Jahrhunderts. Ist es denn nicht kompliziert genug wenn 5 Klassen voneinander erben, muß ich zu allem Überfluss noch an zufällige Stellen hüpfen und dabei Fehlermeldunen verschlucken?

Und was will ein User mit Fehlermeldungen? Der User soll von Fehlermeldungen überhaupt rein gar nichts mitbekommen, sondern er soll verstehen was passiert. Ein Notice: Undefined index: xy schürt nur für Verwirrung, ggf. macht er erneut die gleiche Bestellung, weil er der Annahme ist, dass die Bestellung nicht akzeptiert wurde.

Das erzähl mal meinem Stromdienstleister, auf dessen Website man sich jetzt wieder registrieren kann weil ich eine detailierte Fehlermeldung an den Support geschickt habe. Ich sage auch nicht dass man Notices unbedingt ausgeben muß, errors aber auf jeden Fall. Wenn da was schief läuft hat der User ein Recht damit behelligt zu werden. Ich will nicht zwei STunden Daten eingeben und dann am Ende scheitern, weil im ersten Formular ein Fehler geworfen wurde, der nicht angezeigt wurde.

Was hat das aber mit obigem Problem zu tun? Du leitest ihn doch nur auf eine URL weiter, was dahinter steckt und was wie gemacht wird entscheidest du, der Aufruf sieht nur gescheit und durchdacht aus.

Da gings eher um den Doublepost, war nicht direkt aufs headern bezogen.

Eine 404 Error Seite wäre auch ein gutes Beispiel. Anstatt index.php?a=b&c=d&e=f in der URL stehen zu haben und die Fehlerseite zu präsentieren, kann man den User ganz elegant auf /404, /Beitrag-nicht-gefunden o.ä. weiterleiten, sodass er sofort an der URL sieht, was das Problem ist.

Was denkst du denn wie viele Nutzer sich die URLs anschauen? Das sind vielleicht wir Entwickler, der Rest der Nutzer hat sich schon lange abgwöhnt URLs zu beachten, seit da 20-stellige Zahlen und alphanumerische Strings drinhängen ;D

 

[kling1]

wasn am header redirect falsch? mache ich bei dateidownloads ey und klassennamen schreibt man groß

 

[Daaron]

Was denkst du denn wie viele Nutzer sich die URLs anschauen? Das sind vielleicht wir Entwickler, der Rest der Nutzer hat sich schon lange abgwöhnt URLs zu beachten, seit da 20-stellige Zahlen und alphanumerische Strings drinhängen ;D

Du willst wissen, wer sich URLs anschaut? Es gibt da so einen netten Herrn namens Google, der sich sehr freut, wenn URLs kurz, prägnant und beschreibend sind. example.com/mitglieder.php ist hier WEIT besser als example.com/index.php?page=mitglieder. Wenn du also nicht auch noch extrem komplexe Rewrite Rules schreiben willst sowie ein flexibles Alias Handling, dann ist "eine Datei pro Seite" gar nicht so ineffizient. Effektiver sind lediglich komplexe Mechanismen, wie sie ausgewachsene CMS bieten. Hier ist aber von der Programmier-Seite kaum etwas zu tun, das System ist fertig und kümmert sich.

Übrigens: Noch ein sehr gutes Beispiel für den Header-Einsatz:
Nehmen wir mal einen Webshop, bei dem der Kassenbereich über HTTPS gesichert ist. Alle Artikel-Seiten, das Impressum und sonstige Zeugs kommt via HTTP, um Ressourcen zu sparen. Da es jetzt trotzdem möglich wäre, dass ein User die "kasse.php" über HTTP aufruft, muss der Kassenbereich als erstes prüfen, ob er über Verschlüsselung angesprochen wurde und wenn nicht, auf sich selbst mit Verschlüsselung headern.

Wenn der Einsatz von header() so verkehrt ist, wieso setzen dann verdammt weit verbreitete und beliebte Systeme wie Magento oder Contao trotzdem darauf? header-redirects sind vollkommen in Ordnung. Nur weil du mit deinem Error Handling nicht klar kommst musst du niemandem eine vollkommen legitime und ordentliche Technik madig machen.

 

[mambokurt]

Du willst wissen, wer sich URLs anschaut? Es gibt da so einen netten Herrn namens Google, der sich sehr freut, wenn URLs kurz, prägnant und beschreibend sind. example.com/mitglieder.php ist hier WEIT besser als example.com/index.php?page=mitglieder.

Mag sein, ich mußte noch nie irgendwas auf Google optimiert erstellen.

Übrigens: Noch ein sehr gutes Beispiel für den Header-Einsatz:
Nehmen wir mal einen Webshop, bei dem der Kassenbereich über HTTPS gesichert ist. Alle Artikel-Seiten, das Impressum und sonstige Zeugs kommt via HTTP, um Ressourcen zu sparen. Da es jetzt trotzdem möglich wäre, dass ein User die "kasse.php" über HTTP aufruft, muss der Kassenbereich als erstes prüfen, ob er über Verschlüsselung angesprochen wurde und wenn nicht, auf sich selbst mit Verschlüsselung headern.

Das halte ich für ziemlich akademisch. Ist sicherlich eine der Ausnahmen wo headern wirklich Sinn ergibt, aber bei wie vielen Gelegenheiten kommt das vor?

Wenn der Einsatz von header() so verkehrt ist, wieso setzen dann verdammt weit verbreitete und beliebte Systeme wie Magento oder Contao trotzdem darauf? header-redirects sind vollkommen in Ordnung. Nur weil du mit deinem Error Handling nicht klar kommst musst du niemandem eine vollkommen legitime und ordentliche Technik madig machen.

Wenn der Einsatz von GOTO so verrufen ist, warum bringen es selbst moderne Sprachen immer noch mit? Der header hat klar seine Daseinsberechtigung, aber ein eingesparter header ist trotzdem der bessere header wenn du mich fragst. Ansonsten kein Grund gleich pampig zu werden, ich halte es nur für blödsinnig wegen eines Logins zu headern. Wenn du anderer Meinung bist dann header halt wild durch die Kante, ist ein freies Land ^^

 

[ice-breaker]

Das halte ich für ziemlich akademisch. Ist sicherlich eine der Ausnahmen wo headern wirklich Sinn ergibt, aber bei wie vielen Gelegenheiten kommt das vor?

Das ist ein Muss für jedes SSL-System.

Der header hat klar seine Daseinsberechtigung, aber ein eingesparter header ist trotzdem der bessere header wenn du mich fragst.

und mehr als genug andere, mich eingeschlossen, sehen das genau anders. Der Location-Header ist z.B. absolut nötig um bei POST-Requests das doppelte versehentliche Absenden zu verhindern.

 

[Daaron]

Mag sein, ich mußte noch nie irgendwas auf Google optimiert erstellen.

Tja, unsere Kunden bezahlen uns aber nicht dafür, dass ich irgend welchen eigenartigen header-freien Code schreibe. Unsere Kunden bezahlen uns in erster Linie als Werbeagentur. Die wollen ihre neue Webseite nicht zum Selbstzweck, die wollen das Ding, um Umsatz zu generieren.

SEO ist nach Sicherheit und Stabilität der wichtigste Aspekt überhaupt, wenn man ein Webprojekt anfängt. Wenn für das Projekt ein lausiges Suchmaschinen-Rating zu erwarten ist, dann ist das Projekt direkt verschwendetes Geld und sollte noch einmal durchdacht werden.

Das halte ich für ziemlich akademisch. Ist sicherlich eine der Ausnahmen wo headern wirklich Sinn ergibt, aber bei wie vielen Gelegenheiten kommt das vor?

Wie ich schon sagte: Jede Seite, die einen per HTTPS oder SPDY verschlüsselten Bereich anbietet. Und wieso?
Unverschlüsselte Verbindungen sind billiger. Sie kosten sowohl beim Server als auch beim Client weit weniger Rechenzeit und Bandbreite. Man sollte also soviele Ressourcen wie möglich unverschlüsselt rauspumpen. Da einige URLs innerhalb der Seitenstruktur (z.B. eben der Kassenbereich bei Shops, ein Webmailer,...) aber hinter HTTPS gehören muss man hier schlichtweg per Header umschalten.

Wenn der Einsatz von GOTO so verrufen ist, warum bringen es selbst moderne Sprachen immer noch mit?

GOTO wird aber, im Gegensatz zu Location Headers, nicht mehr aktiv benutzt. Es ist nur da.
Es gibt keinen effektiveren Weg, um das Protokoll zu wechseln, auf externe Seiten weiterzuleiten oder POST/GET zu bereinigen.

ich halte es nur für blödsinnig wegen eines Logins zu headern.

OK, kleiner Use Case, wieso auch ein Login einen Location Header benötigt/benötigen kann...
Ein User soll nach dem Login auf seine private Mailbox, in seine Rechnungsübersicht oder sein Dashboard weitergeleitet werden. Wie löst du das ohne Redirect Header? Ein Redirect-Header ist eine kurze Zeile:
Wenn Login-Formular erfolgreich -> Header-Redirect auf index.php/dashboard

Wie viele Zeilen brauchst du? Wie konsistent ist dabei deine URL? URL-Konsistenz ist WICHTIG! Eine URL sollte immer dasselbe Ergebnis liefern. index.php?site=login enthält immer das Login-Script, niemals das Dashboard.

Niemand bezahlt dich für 100 Zeilen kryptisches Geschreibsel, wenn du dein Ziel mit einer klaren und syntaktisch korrekten Zeile erreichen kannst. Wenn dich doch jemand für deine 100 Zeilen bezahlt: Hoffe bloß nicht, dass dieser Jemand jemals von Leuten wie ice-breaker oder mir hört... denn unsere Arbeitsweise ist schneller und somit billiger.

und mehr als genug andere, mich eingeschlossen, sehen das genau anders. Der Location-Header ist z.B. absolut nötig um bei POST-Requests das doppelte versehentliche Absenden zu verhindern.

...in Verbindung mit nem entsprechenden Token.

 

[Physically]

Ist ja ne schöne Diskussion draus geworden, aber was soll ich jetzt nehmen?

Beispiele:
ComputerBase Forum, ich logge mich ein und es steht sie werden nun weitergeleitet oder klicken Sie hier. Sowas ist doch auch sicher bzw. ok, oder?

 

[Daaron]

Wie schon gesagt:
"Wenn Userdaten gültig => speichere Login in Sessionvariable & führe Header Redirect aus"

Die passenden PHP-Zeilen dafür kriegst du schon allein hin.