ASP.NET - Response.Redirect Not Populating Url Referrer

Question

I feel like i've done this a ton of times, but i can't for the life of me figure out what is going wrong.

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("/");
}

If i type "/SingleSignOn.aspx" in the URL, it redirects to Default.aspx, but the referrer is null.

What am i missing here?

What im trying to do (this is a simplified example), is on any page, i will have some JavaScript to do the following:

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

Which, you guessed it, signs the user in, and redirects to the homepage.

But i need to build logic into that JavaScript to not redirect to the SingleSignOn.aspx page if we just came from there.

Does the referrer only get populated by actual link user clicks?

How can i do this then? I don't want to use QueryString because i dont want to see that in the URL.

The only other option i can think of is Session.

Please help. =(

Phenology

Curious to know why r you redirecting from java-script. The scenario that you describe, I would have checked on server side (probably OnInit of base page) if user is authenticated or not. If not then redirect to the page that does it. – Determine

@Determine - it's complicated. Basically im working on a Facebook Connect app - after the page has loaded, javascript lets me know i am able to sign them in, hence i redirect. I dont know if i can sign them until until client-side API's are executed. – Phenology

Well, you can add your own cookie when user is authenticated and then from javacript, you can see if the cookie exists or not to decide whether to redirect or not. If you don't wish to use cookie then your pages (should be done in base page) has to set some JS variable if user is authenticated. Difference between cookie approach is that cookie needs to set only once (in SingleSignOn.aspx) while js variable must be set in every page (hence the logic should be put in a common base page). – Determine

@Determine - lol, literally answered same thing at same time. – Phenology

Answer 1

So, i've done some Google'ing to find my answer.

No thanks to Stack Overflow - kidding, =)

So the URL Referrer is only populated by an actual client-click (anchor tag, button).

Not when you manually put it in the URL (which is what my JavaScript is doing).

The solution i am doing to have to with is to create a cookie on the SingleSignOn.aspx page, and read that cookie from the JavaScript before i redirect again.

Just what i need, more cookies. =(

Unless someone here has a better idea, that's what ill be going with.

Phenology

Thanks a lot man, I had the need for a very similar solution because I was modifying a hodgepodge wizard where you could actually skip steps because they weren't verifying the referrer. I tried the UrlReferrer too and it worked in development and failed when deployed to IIS. A cookie solution was perfect! – Davison

Answer 2

It's pretty late but as you manage response. redirect content, you could use query parameters as response.redirect("/?url=home.aspx&q=whatever").

Then you can capture it when page load or init and take the proper action about

Juratory

Was perfect for my use case. – Aid

Answer 3

Just a hunch, but try using an absolute url instead / including even the http:// part.

That said, you shouldn't rely on the UrlReferrer from being there, as it can be stripped off from the client side (by addins, not sure if even by some browser configs).

Ossiferous

Yeah i tried that, see my answer above - only a client click (button, anchor) will cause the referrer http header to be populated. – Phenology

@Phenology k, but Redirect("/") is not exactly what I mentioned, it'd be like Redirect("myserver.com/"). – Ossiferous

Yes - tried that, also tried it in a brand new web project (so no other factors - ie URL rewriting would get in the way). No go. Anyway the cookie solution is working, and the fact i need to "check" the previous page from client-side, makes it easy the fact its a cookie. Thanks for your help tho. – Phenology