2010-09-17 7 views
12

Ich fühle mich wie ich es schon oft getan habe, aber ich kann nicht für das Leben von mir herausfinden, was schief läuft.ASP.NET - Response.Redirect Nicht auffüllen URL Referrer

Default.aspx:

protected void Page_Load(object sender, EventArgs e) 
{ 
    var r1 = Request.UrlReferrer; // null 
    var r2 = Request.ServerVariables["HTTP_REFERRER"]; // null 
} 

SingleSignOn.aspx:

protected void Page_Load(object sender, EventArgs e) 
{ 
    Response.Redirect("/"); 
} 

Wenn ich in der URL "/SingleSignOn.aspx" eingeben, um es zu Default.aspx umleitet, aber der Referrer ist null.

Was fehlt mir hier?

, was im zu tun (das ist ein vereinfachtes Beispiel) versucht, auf jeder Seite ist, werde ich einige JavaScript muss folgendes tun:

window.location.replace('~/SingleSignOn.aspx'); 

Which, Sie ahnen es, unterzeichnet den Benutzer in, und leitet auf die Homepage um.

Aber ich muss Logik in dieses JavaScript einbauen, um nicht zur SingleSignOn.aspx Seite umzuleiten, wenn wir gerade von dort kamen.

Wird der Referrer nur durch tatsächliche Linkbenutzerklicks gefüllt?

Wie kann ich das dann tun? Ich möchte QueryString nicht verwenden, weil ich das in der URL nicht sehen möchte.

Die einzige andere Option, die ich mir vorstellen kann, ist Session.

Bitte helfen. = (

+0

Neugierig zu wissen, warum Sie umleiten java-script Das Szenario, das Sie beschreiben, hätte ich auf der Serverseite (wahrscheinlich OnInit der Basisseite) überprüft, ob der Benutzer authentifiziert ist oder nicht Seite, die es tut. – VinayC

+0

@VinayC - es ist kompliziert.Im Grunde arbeite ich an einer Facebook Connect App - nachdem die Seite geladen wurde, lässt Javascript mich wissen, dass ich in der Lage bin, sie anzumelden, also ich Redirect. Ich weiß nicht, ob ich sie signieren kann, bis clientseitige APIs ausgeführt werden. – RPM1984

+0

Nun, Sie können Ihren eigenen Cookie hinzufügen, wenn Benutzer authentifiziert wird und dann von javascript können Sie sehen, ob der Cookie existiert oder nicht, um zu entscheiden, ob umgeleitet werden soll oder nicht. Wenn Sie kein Cookie verwenden möchten, müssen Ihre Seiten (sollten auf der Basisseite ausgeführt werden) eine JS-Variable festlegen, wenn der Benutzer authentifiziert wird. Der Unterschied zwischen dem Cookie-Ansatz besteht darin, dass der Cookie nur einmal (in SingleSignOn.aspx) gesetzt werden muss, während die Variable js auf jeder Seite gesetzt werden muss (daher sollte die Logik in eine gemeinsame Basisseite eingefügt werden). – VinayC

Antwort

9

So habe ich einige Google'ing getan meine Antwort zu finden

Keine dank Stack-Überlauf -. Kidding, =)

So die URL Werber nur durch eine tatsächliche Client bestückt ist -Klick (Anker-Tag, Schaltfläche).

Nicht, wenn Sie es manuell in die URL (was ist, was mein JavaScript tut).

Die Lösung, die ich tun muss, ist ein Cookie auf der SingleSignOn.aspx Seite zu erstellen, und lesen Sie das Cookie aus dem JavaScript, bevor ich erneut umleiten.

Genau das, was ich brauche, mehr Cookies. = (

Es sei denn hier jemand eine bessere Idee hat, dann ist es das, was krank mit gehen

+1

Vielen Dank, ich hatte die Notwendigkeit für eine sehr ähnliche Lösung, weil ich einen Mischpult-Assistenten geändert habe, wo Sie tatsächlich Schritte überspringen konnten, weil sie den Referrer nicht überprüft haben. Ich habe auch den 'UrlReferrer' ausprobiert, der in der Entwicklung funktioniert und bei der Bereitstellung in IIS fehlgeschlagen ist. Eine Cookie-Lösung war perfekt! –

0

nur eine Ahnung, aber versuchen Sie stattdessen/darunter auch die http eine absolute URL:.. // Teil

Nichtsdestotrotz sollten Sie sich nicht darauf verlassen, dass der UrlReferrer da ist, da er von der Client-Seite abgezogen werden kann (durch Add-Ins, nicht sicher, ob durch einige Browserkonfigurationen)

+0

Ja, ich habe das versucht, siehe meine Antwort oben - nur ein Client-Klick (Button, Anker) wird dazu führen, dass der Referrer-HTTP-Header aufgefüllt wird. – RPM1984

+0

@ RPM1984 k, aber Redirect ("/") ist nicht genau das, was ich erwähnt habe, es wäre wie Redirect ("http://myserver.com/"). – eglasius

+0

Ja - probierte das, probierte es auch in einem brandneuen Web-Projekt (also keine anderen Faktoren - also URL-Rewriting würde in die Quere kommen). No Go. Wie auch immer, die Cookie-Lösung funktioniert, und die Tatsache, dass ich die vorherige Seite von der Client-Seite "überprüfen" muss, macht es einfach, dass es ein Cookie ist. Danke für deine Hilfe. – RPM1984

Verwandte Themen