Bleibt bei einer 302-Weiterleitung die Referer-Zeichenkette erhalten?

Question

Ich muss den Benutzer von einer Seite zu einer anderen umleiten, aber ich muss die ursprüngliche Referer-Zeichenfolge beibehalten. Wenn sie also zum Beispiel auf http://www.othersite.com/pageA.jsp klicken sie auf einen Link, der sie zu folgenden Seiten führt http://www.example.com/pageB.jsp die dann eine 302-Umleitung zu http://www.example.com/pageC.jsp muss der Referer-String Folgendes enthalten http://www.othersite.com/pageA.jsp

Ist dies das normale Verhalten für eine 302-Weiterleitung? Oder wird mein ursprünglicher Referer fallen gelassen, zugunsten von http://www.example.com/pageB.jsp ? Das wäre nicht wünschenswert.

Ich weiß nicht, ob es einen Unterschied macht, aber ich arbeite in JSP, und ich verwende response.sendRedirect() um die 302-Weiterleitung auszuführen.

Ich sollte erwähnen, dass ich ein Experiment damit gemacht habe, und es scheint, dass die ursprüngliche Referer-Zeichenkette ( http://www.othersite.com/pageA.jsp ), aber ich wollte nur sichergehen, dass dies das normale Standardverhalten ist und nicht etwas Seltsames auf meiner Seite.

---

Obwohl ich derzeit eine 302-Umleitung verwende, könnte ich stattdessen wahrscheinlich eine 301-Umleitung verwenden. Wissen Sie, ob das Verhalten bei 301-Weiterleitungen zuverlässiger ist?

Answer 1

Ich weiß nicht, wie es sich mit der 302 verhält, aber ich habe heute die 301 auf einigen Browsern getestet, hier die Ergebnisse:

SCENARIO Benutzer klickt auf einen Link auf domainX, der auf domainA verweist. domainA leitet eine 301-Weiterleitung auf domainB um.

• IE8 referer bei der Landung auf DomainB ist: DomainX (auch bei Verwendung von InPrivate-Browsing und auch wenn der Benutzer den Link in einer neuen Registerkarte öffnet)
• Safari4 referer bei der Landung auf DomainB ist: DomainX (auch wenn der Benutzer den Link in einer neuen Registerkarte öffnet)
• FF3.6.10 referer bei der Landung auf DomainB ist: DomainX (auch wenn der Benutzer den Link in einer neuen Registerkarte öffnet)
• Chrom5 referer bei der Landung auf DomainB ist: DomainX ( es sei denn, Benutzer öffnet Links in neuer Registerkarte)
• Chrom26 referer bei der Landung auf DomainB ist: DomainX (auch wenn der Benutzer Links in einer neuen Registerkarte öffnet)

Answer 2

Die kurze Antwort lautet, dass dies im entsprechenden RFC 2616 nicht angegeben ist. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 entweder für die Kopfzeile Referer oder den Statuscode 302.

Am besten machen Sie einen Test mit mehreren Browsern, um zu sehen, ob es ein einheitliches Verhalten gibt.

Für eine vollständige Umleitung kodieren Sie den ursprünglichen Referrer in der Umleitungs-URL, damit Sie ihn garantiert abrufen können.

Answer 3

Gute Frage. In diesem Fall hängt das Senden des Referers vollständig vom Browser ab (weil der Browser angewiesen wird, eine weitere Anfrage an die neue Ressource zu stellen).

RFC 2616 schweigt zu diesem Thema:

Die angeforderte Ressource befindet sich vorübergehend unter einem anderen URI. Da die Umleitung gelegentlich geändert werden kann, SOLLTE der Client für künftige Anfragen weiterhin die Request-URI verwenden. Diese Antwort ist nur dann cachefähig, wenn sie durch ein Cache-Control- oder Expires-Header-Feld gekennzeichnet ist.

Ich würde nicht darauf vertrauen, dass der Browser den richtigen Referer weiterleitet. Ich wette, es gibt mindestens einen, der etwas anderes sendet als die anderen.

Abhilfe

Wenn Sie die Möglichkeit haben, fügen Sie doch einfach eine ?override_referer=<old_url> Parameter auf die URL, zu der Sie umleiten, und analysieren Sie diesen Wert anstelle von HTTP_REFERER.

Auf diese Weise können Sie sicher sein, dass Sie immer das richtige Ergebnis erhalten, und Sie verlieren nichts an Sicherheit: Der Referer kann so oder so gefälscht werden.

Answer 4

Ich hatte das gegenteilige Problem: Ich wollte, dass der Referer "SeiteB" ist, aber keiner der aktuellen Browser verhält sich so...

Also habe ich es mit einer HTML-Weiterleitung auf Seite B versucht (anstelle einer 301- oder 302-Weiterleitung):

<meta http-equiv="refresh" content="0; url=pageC.jsp" />

Und das Ergebnis war überraschend:

• Referer ist SeiteB mit Chrome
• Referer ist bei FireFox und IE LEER!

Ich hoffe, dies kann helfen

Answer 5

Spät zur Party, aber heute HTTP-Redirects (sowohl über HTTP-Header oder Meta http-equiv) nicht senden die umleitende Seite in Referer-Header.

Javascript-Weiterleitungen scheinen in allen Fällen die weiterleitende Seite im Referer-Header zu senden. <script>window.location.href="..."</script>

Ich hatte das folgende Szenario:

• Landing Page auf Domain A;
• Webanwendung auf Domäne B.

Wenn ein Benutzer, der bereits in der Web-App eingeloggt ist, die Landing Page A besucht (die zum Beispiel von einer Suchmaschine oder einer Pay-per-Click-Kampagne kommt, die den Großteil unseres Traffics ausmacht), soll er automatisch zur Web-App B weitergeleitet werden. Es ist ein CORS-Szenario, aber ich kontrolliere beide Domains.

Ich hätte das erreichen können, indem ich ordnungsgemäß domänenübergreifende Cookies gesetzt/gelesen hätte (es funktioniert mit HTTPS + Secure + SameSite-Cookie-Attributen), aber es hatte einige Nachteile, wenn der Benutzer sich von der Webanwendung abmeldete oder die Browser-Cookies nur für eine der beiden Domänen löschte oder die Sitzung auf dem Server ablief.

Also habe ich eine andere Lösung gefunden: Ich habe einen Endpunkt "/redirectIfNotLogged" in meiner Webanwendung B implementiert. Wenn jemand die Landing Page A besucht, wird eine HTTP-Weiterleitung zum obigen Endpunkt auf der Domäne B durchgeführt. Dieser Endpunkt liest das Cookie und überprüft die Sitzung. Wenn der Benutzer bereits angemeldet ist, wird er zum Dashboard der Webanwendung weitergeleitet, andernfalls wird er zurück zur Website weitergeleitet. Um eine unendliche Weiterleitung zu vermeiden, muss ich wissen, ob wir von einer Weiterleitung kommen, die von der Webanwendung betrieben wird. Wir würden auf die ursprüngliche URL umleiten. Wir würden nicht zu einer anderen Seite auf Domäne A umleiten oder einen Abfrage-String anhängen. Also prüfe ich den HTTP-Referer-Header. Dabei stellte ich fest, dass bei Weiterleitungen über Javascript der Referer-Header gesendet wird, bei HTTP-Weiterleitungen hingegen nicht. Da die Webanwendung Javascript benötigt, um zu funktionieren, ist dies kein Problem.

Ich experimentiere noch damit, ob einige Antivirenprogramme oder Firewalls (wir verwenden überall HTTPS, daher sind mir Cloud- oder Unternehmens-AV/FW oder alles, was nicht auf dem lokalen Rechner installiert ist, egal) den Referer-Header entfernen. In solchen Fällen vermeide ich einfach eine unendliche Weiterleitung und entscheide mich für die Anzeige von Landing Page A (oder Web-App B)