(interne) Herkunftsseite - alternative zum HTTP_REFERER

WhiZZler

WhiZZler

Chancentod²
ID: 85586
L
6 Mai 2006
588
32
begrüße!

in meinem projekt möchte ich an mehreren stellen direkt auf die seite weiterleiten, von der der benutzer gerade kam.. also zum beispiel ganz klassisch bei einem login.. beim login kann man das ja recht schön mit einem hidden field lösen.. ich würde sowas aber gerne an einigen anderen stellen verwenden, bei denen direkt ein link geklickt werden soll und kein formular abgeschickt wird..

der erste gedanke war hierbei der HTTP_REFERER.. aber die idee habe ich dann ebenso schnell wieder verworfen, weil das wohl zu unverlässig ist und ne missglückte weiterleitung an den stellen sehr störend wäre..

meine zweite idee war es, die letzten 3 (oder 2, oder 5 oder was auch immer) besuchten uris in der session zu speichern um dann jeweils an die gewünschte stelle weiterleiten zu können (so in etwa wie bei javascript mit history.back(x))

der dritte gedanke war es das ganze einfach entweder in das hidden feld zu schreiben oder bei den links dann als get parameter zu übergeben.. das ist wohl die einfachste und auch so ziemlich die sicherste möglichkeit, aber ich finde es irgendwie ziemlich unschön.. zumal man die uris dann noch irgendwie kodieren müsste, weil sonst der router von zend durcheinandern kommt..

mich würden ein paar meinungen zu dem thema interessieren ;)

danke im vorraus
mfg
whizzler
 
Der Referer is doch eigentlich ganz ok. Und er is völlig unkomplizit.
Wer Bullshit als Referer sendet, darf sich dann auch nicht beschweren, wenn die Weiterleitung nicht funktioniert.

Aktuelles Beispiel: Lösch mal hier im Forum aus der Nachrichtenverfolgung verfolgte PNs raus. Ich lande danach immer auf der Portal-Startseite :ugly:

Deine zweite Idee kostet halt zusätzlichen Aufwand bei jedem Seitenaufruf.

Das Input-Feld is quasi der Kompromis: Lösung 2, aber nur, wenn es notwendig is. Dafür hast du dann den hässlichen GET-Parameter sichtbar in der Adresszeile.


Ich persönlich würde entweder Lösung 1 oder Lösung 2 nehmen.

Lösung 2 bietet sich an, wenn du sowieso schon bei jedem Seitenaufruf irgendwas loggst, z.B. um ne "Wer ist grade online?"-Übersicht zu generieren. Hast du sowas nicht, würd ich die Primitiv-Referer-Lösung nehmen.

edit:
Noch was: Du willst das für Links haben? Wieso änderst du nicht die href-Attribute der Zurück-Links explizit ab? Musst halt wegen Suchmaschinen aufpassen, dass die immer dieselben Links kriegen.
 
Ich finde die ersten beiden Loesungen sehr gut. Referer is so die standard variante, aber geht eben nur eine Seite zurueck. Wenn du ein Formblatt hast das mehrstufig is, oder noch irgendwie eine Auswahl hierarchie, koennte das eventuell ein Problem werden.

Die Session is fuer so etwas auch sehr gut geeignet, besonders da es (wenn du eh schon sessions verwendest) nur eine variablen zuweisung mehr is (und wenn dass performance kritisch is, machst du eh etwas falsch :evil:).

Ich mach meist eine zwischenloesung, fuer schnelle, einstufige, Sachen einfach den Referer und sonst gewisse Speicherpunkte definieren an denen die Aktuelle position in der Session gespeichert wird :mrgreen:
 
die session wird bei mir eh bei jedem seitenaufruf initialisiert (überprüfung, ob der user eingeloggt ist).. deswegen werde ich es dann wohl mit der session versuchen und dort die letzten 3 besuchten seiten speichern..

dem referer trau ich irgendwie nicht so ganz..

ich bin momentan bei meinen eltern zu hause.. da ich auf meinem eigenen rechner linux benutze dachte ich mir ich teste die seite, an der ich momentan bastle, mal mit dem ie.. und da funktioniert das mit dem referer nicht :ugly: ich habe keine ahnung warum.. eventuell liegt es an einer der gefühlten 30 toolbars, die da versehentlich installiert wurden :ugly:

danke euch auf jeden fall für die antworten :)
 
Meiner erfahrung nach (https://www.klammbank.net/s/ fuer meine Traffic stats) sind Browser die Falsche Referer uebergeben relativ selten: ~2.8% geben keine weiter, ~0.3% geben fehlerhafte Referer weiter, also ich denke eigentlich sollte die Referer Methode noch nicht als totgeschrieben gehandelt werden.

Und wie theHacker schon meinte: wer einen kaputten Browser benutzt darf sich nicht beklagen wenn es nicht so funktioniert wie geplant :evil:
 
oha.. an das mit dem tabbed browsing hatte ich gar nicht gedacht.. aber das macht das ganze in der tat unbrauchbar.. dann werde ich wohl doch wieder den referer benutzen.. scheint mir das geringste übel zu sein ;)
 
HTTP_REFERER wird gern bei Hacks verwendet.
Ich würde davon abraten.
Was man in der Session speichern könnte, legt man in der DB ab.
Somit sind mehrseitege Formulare einfach zu tracken und bei Abbruch
an gleicher Stelle weiterführbar.

Ich nutze keine Referer
 
tobomator schrieb:
HTTP_REFERER wird gern bei Hacks verwendet.
Ich würde davon abraten.
Was man in der Session speichern könnte, legt man in der DB ab.
Somit sind mehrseitege Formulare einfach zu tracken und bei Abbruch
an gleicher Stelle weiterführbar.

Ich nutze keine Referer
Zum Vergrößern anklicken....

Wie es schon gesagt wurde, kann der Referer nur vom Browser des Besuchers kommen, sollte dieser Müll verschicken ist der Besucher eben "selber schuld".
 
Der Browser verschickt kein Müll.

Du kannst eine HTTP Antwort "faken" in dem Du einen REFERER in das Headerpaket mit einbaust und warst aber nie dort. Davon schon mal was gehört oder nicht ?

Einfache aber sichere Methode is ein Hiddenfeld, welches verschlüsselt immer die aktuelle Seite beinhaltet. So mach ich es jedenfalls. Ein Zurück im Browser is egal und Tabbed dabei auch
 
tobomator schrieb:
Du kannst eine HTTP Antwort "faken" in dem Du einen REFERER in das Headerpaket mit einbaust und warst aber nie dort. Davon schon mal was gehört oder nicht ?
Zum Vergrößern anklicken....

Da musst du nicht viel "faken". Für FF gibts viele Addons mit denen du den Referer ändern kannst. Aber was soll das bitte bei einem "Hack" helfen?
Ausser natürlich man macht solchen Müll wie:
PHP: 
<?
include($_SERVER['HTTP_REFERER']);
?>

tobomator schrieb:
Einfache aber sichere Methode is ein Hiddenfeld, welches verschlüsselt immer die aktuelle Seite beinhaltet.
Zum Vergrößern anklicken....

Wieso sollte das sicher sein? Eine Verschlüsslung kann meistens Geknackt werden... Und man kann ohne weiteres den Inhalt davon manipulieren.
Aber was bringt einem potentiellen "Hacker" das? (Vorausgesetzt das Script macht nicht so einen Müll wie oben angegeben...)
 
Xot schrieb:
Eine Verschlüsslung kann meistens Geknackt werden...
Zum Vergrößern anklicken....
Eine Verschlüsselung kann immer geknackt werden. Es gibt schließlich eine Inversoperation und die kann ein Angreifer auch herausbekommen.

Die Frage, die sich mir da genauso wie jedem anderem steht: Was soll das bringen? Ein Angreifer knackt den Code, um die URL zu ändern, auf die sein Browser zurückleitet? Dann kann er doch gleich die URL in die Adresszeile eingeben :ugly:
 
theHacker schrieb:
Eine Verschlüsselung kann immer geknackt werden.
Zum Vergrößern anklicken....

Nur die Frage ist ob dann der Angreifer noch lebt :D
Vielleicht verschlüsselt er ja die Links der Seiten per AES mit einem 10240 Bit grossen Key :ugly:

Aber ja wir wollen auf das selber heraus, nämlich dass es sinnlos ist das ganze zu verschlüsseln :LOL:
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben