history go(-1) verhindern ?

[tschekowski]

Hi,

Kann man es irgendwie verhindern, dass man in der History eine odere mehrere Seiten zurückgeht oder das wenigstens eine Fehlermeldung kommt ?
Vielleicht mit Hilfe von PHP oder javascript ?



tschekowski

[Blutgerinsel]

Hi,

Kann man es irgendwie verhindern, dass man in der History eine odere mehrere Seiten zurückgeht oder das wenigstens eine Fehlermeldung kommt ?
Vielleicht mit Hilfe von PHP oder javascript ?



tschekowski

Kann du mal konkret eine Situation schildern bei der dies erforderlich sein muss/soll ?
Willst du eine Reloadsperre, IP-Sperre oder was auch immer?
BTW: Es ist immer gut den Sachverhalt darzulegen

[tschekowski]

es geht um ein Bestellformular, bei dem man Adresse, Email, etc eingeben muss. Bei der Email ist es wichtig, dass sie in der Datenbank nicht doppelt vorhanden ist. Wenn man die Bestellung jetzt abschickt und dann auf "zurück" geht kann man die Bestellung nocheinmal abschicken obwohl die gleiche Emailadresse angegeben wurde was aber wie gesagt das System durcheinander bringen würde (2 gleiche Emails).
Eigentlich könnte man eine Routine einbauen, die verhindert, dass 2x mit der gleichen Emailadresse bestellt wird, wenn man aber auf zurück geht gibt es noch einige andere Dinge die dann nicht so passen wie sie sollten, deshalb wäre es gut wenn man es irgendwie verhindern könnte, dass man auf zurück gehen kann und die gleiche Seite nochmal neu sieht.
(Fehlermeldung wie die Seite ist nicht mehr aktuelell würde auch reichen, dann müsste man die Seite wieder neu laden und man kommt zum anfang zurück)
Gibt es dafür eine Lösung ?


tschekowski

[Blutgerinsel]

ehm wie ist deine DB konzipiert?
Was ist dein Primary Key.....Dir ist nicht klar das ein Primary Key als schneller Tableindex herhaltet und einen Datensatz eindeutig identifiziert sprich es ist unmöglich einen doppelten Primary Key einzufügen.....

Wenn du die Seite via Header weiterleitest oder einfach dem Formular eine ID verpasst kannst du z.B. via Session feststellen ob das Formular schon gesendet wurde.....

Indem nachdem senden einfach die ID in die Session eingefügt wird (nur im fehlerlosen Fall) und dann abgefragt wird....

was die Newsgroup auch selbstklärend als häufige Frage mit ins FAQ aufgenommen hat -> http://www.php-faq.de/q/q-phplib-reloads.html

[MrMind]

also ne E-Mail Feld als Primary Key zu kennzeichnen ist nach meiner Meinung eine net so gut Idee wenn ein Shop lediglich die E-Mail Adresse benötigt.
Da der User bestimmt an einem anderen Tag noch was kaufen möchte und dann die selbe E-Mail Adresse verwenden wird.

Aber man kann auch beim speichern der Daten sowie senden der E-Mail eine Überprüfung machen. Es muss nur die E-Mail Adresse und die momentane Zeit beim senden gespeichert werden in die DB.

Beim senden und speichern sollte dann wie folgt kontrolliert werden:

Code: Alles auswählen

$sql = "SELECT time FROM tabelle WHERE email='" . $email . "' ODER BY time DESC LIMIT 1";

if( !$result = mysql_query($sql) )
{
    //Speichern der Daten und senden der Email
}
else
{
    $row = mysql_fetch_array($result);
     
    if( ($row['time'] + 300) < time() )
    {
         //Speichern der Daten und senden der Email
     }
     else
     {
          //Abbruch da wahrscheinlich ein Reload
      }
}

Das Skript ruft den letzten Eintrag mit der E-Mail Adresse auf, ist keiner enthalten, wird gespeichert, wenn doch, dann wird überprüft ob der Letzte Eintrag vor 5 Min. (300 sekunden) war, wenn ja, dann wird gespeichert, ansonsten abbruch, da ein Robot das sein könnte oder der User ein Reload etc. gemacht hat.

Mfg
MrMind

[Blutgerinsel]

also ne E-Mail Feld als Primary Key zu kennzeichnen ist nach meiner Meinung eine net so gut Idee wenn ein Shop lediglich die E-Mail Adresse benötigt.

ich nehme mal einfach an das man sich mit der email als Usernamen anmeldet und auch keine autoincrement Spalte zugrunde liegt.....

Man könnte auch ein Unique auf die Spalte setzen um das ganze eindeutig zu identifizieren

[k-5]

naja sicherheitskontrollen sollte man eh immer machen .. vonwegen doppel eintraege usw ..

was aber zusaetzlich recht angenehm ist .. bei der entsprechenden seite(die seite die die daten in die db eingibt) einen header redirect zurueck zugeben (auf ne "alles ok" seite oder was aehnliches)

dadurch steht in der history nurnoch die seite drin auf die du verwiesen hast .. aber nichtmehr die die fuers eintragen verantwortlich ist ..

auch wird dadurch das popup mit dem "post daten muessen neu gesendet werden" vermieden ..

[Blutgerinsel]

naja sicherheitskontrollen sollte man eh immer machen .. vonwegen doppel eintraege usw ..

was aber zusaetzlich recht angenehm ist .. bei der entsprechenden seite(die seite die die daten in die db eingibt) einen header redirect zurueck zugeben (auf ne "alles ok" seite oder was aehnliches)

dadurch steht in der history nurnoch die seite drin auf die du verwiesen hast .. aber nichtmehr die die fuers eintragen verantwortlich ist ..

auch wird dadurch das popup mit dem "post daten muessen neu gesendet werden" vermieden ..

ein Header sent ist aber nur möglich sofern vorher kein Header gesendet wurde, dies ist daher meistens nicht möglich es sei denn man findet das unschöne Fehlermeldungen hübsch aussehen.....Oder es findet keine Ausgabe vorher statt

Lösung via meta refresh sind dagegen schon sinnvoller und auf möglich......Javascript sollte man dagegen meiden da dies sehr oft ausgeschaltet wird.....

Aber auch Meta Refresh ist abschaltbar.....Folglich bleibt nur noch die Lösung via Session um todsicher derartiges abzufangen und im schlimmsten Fall verweigert die DB aufgrund des unique einfach den Eintrag....

[k-5]

hm .. bei meinen seiten kommt am schluss immer alles aus der template klasse raus .. vorher gibts keine ausgaben ..

aber notfalls .. es gibt die ob_start() funktion .. damit kriegt man (fast) alle "header already send" probleme vom tisch .. (damit findet die ausgabe sowieso immer am ende des scripts statt) .. und solang die seite keine halbe minute zum berechnen braucht ist das performance technisch auch kein problem ..

siehe auch ..

http://de3.php.net/manual/de/ref.outcontrol.php

fuer ein funktionierendes beispiel .. beim eintragen in mein gb auf www.k-5.de .. (selbst das cookie wird noch nach der ausgabe gesetzt .. )


du verwendest tatsaechlich meta redirects ? .. und sowas von jemanden der frames verteufelt ..

[Blutgerinsel]

hm .. bei meinen seiten kommt am schluss immer alles aus der template klasse raus .. vorher gibts keine ausgaben ..

aber notfalls .. es gibt die ob_start() funktion .. damit kriegt man (fast) alle "header already send" probleme vom tisch .. (damit findet die ausgabe sowieso immer am ende des scripts statt) .. und solang die seite keine halbe minute zum berechnen braucht ist das performance technisch auch kein problem ..

siehe auch ..

http://de3.php.net/manual/de/ref.outcontrol.php

fuer ein funktionierendes beispiel .. beim eintragen in mein gb auf www.k-5.de .. (selbst das cookie wird noch nach der ausgabe gesetzt .. )


du verwendest tatsaechlich meta redirects ? .. und sowas von jemanden der frames verteufelt ..

Nicht jeder hat da eine Template Klasse rumstehen und nunja die Pufferung ist wie du schon sagst bei rechenintensiven Sachen nicht gerade optimal.......

und was bitte ist an meta redirects so verwerflich? Wenn ich eine Statusausgabe gebe "Beitrag wurde eingetragen". Dann möchte ich natürlich verhindern das der Server hier aussetzt und deshalb gebe ich dem Client die Aufgabe nach 5 sec. z.B. umzuleiten und wenn nunmal meta redirects off sind steht ein Link der seinen Zweck erfüllt....

Ansonsten sehe ich keinen Grund meta redirects zu verwenden.......

Selbst Lösungen via Session müssen nicht sein wenn ich eine Konstante setze wenn es erfolgreich eingetragen wurde und diese vor dem Eintragen z.B. abfrage hab ich das Problem auch nicht.... Und diese Konstante entferne ich in der Standardausgabe.....

Also wo ist das Problem nun eigentlich?