When browser sets the "referrer" in HTTP Request header? - asp.net

I have a login page and users from different domains are redirected to this page for the purpose of SSO. I use the referrer HTTP Header field to know where the user has come from, thus on successful login, I return him/her back to his/her original domain.
But sometimes my referrer is not set, while other times it's set. Why?

Users can come to your page using different methods:
By entering the URL of your page, directly into the address bar of the browser
By clicking a link to your site from another site
By reloading your current page
By Submitting a form on your site (sending POST request back to your site)
By navigating through back/forward buttons of your browser.
By being redirected through a previous page to the current page.
Now, browsers really differ in how and when they set referrer header field. But as a general rule, you can be sure that on link click, or on submitting a form (post request), they set referrer field. Also if you have come to the current page via a redirect or a link, browser still preserves referrer header on F5 (page reload).
If you see that your referrer field is empty, it's because someone knows your Login page URL and enters that directly into the address bar, or someone has bookmarked it, so sends a GET request.
Generally, you shouldn't always expect the referrer field, because it's outside your control. You should use cookies, or query strings, because they are under your control.

the other thing is that some user may have referer option set as disabled in their browsers as a part of browser security settings.

Related

Is there a way to track an URL traffics if the page doesn't exist but was directed to a working page?

A user enters https://example.com/mypage on the browser
.httaccess redirects to https://example.com/myfinallandingpage
I would like to track the traffics of /mypage.
/mypage is not an actual page, but /myfinallandingpage is a working page.
Does anybody know a way to do this?
Out of the box you can't measure server-side redirects such as 301 or 302 since the browser JavaScript, and thus Google Analytics won't be executed on the redirect source pages.
However you can by doing a little customization:
Insert a URL parameter on the redirect destination page eg https://example.org/destination-page?ref=https://example.org/source-page and track whatever you want on that destination apge
Perform server-side tracking: you could handle your redirects at PHP level, allowing you to use a GA server-side tracking library with GA Client ID retrieved via the cookies in HTTP headers

Universal Analytics and login redirect

As part of user flow on my site, user is redirected to a different domain that is not under my control, where he logs in and is then redirected back to my site.
Google analytics fail to correctly display the user flow, showing the callback URL as a new landing page, which is obviously wrong.
I am considering rewriting referrer on the callback page, but it seems like a very hacky solution to a common problem.
Is there a standard way to connect the flow after a redirect?
You must enter the domain of that site in the Referral exclusions list in the Properties settings.

Facebook request got redirect

Currently my client have 2 websites, for example: abc.com and us.abc.com. They want that everytime an user from US access abc.com, he/she will be redirected to us.abc.com. That can be solved very easy, however after solved that issue, I have ran into another issue related to Facebook.
That's when an user browse abc.com and they click share facebook button somewhere in the website, what was shared is always what appear in the home page of us.abc.com.
What I think is that because Facebook server is in US, so when facebook made the request, it was redirected to us.abc.com => Cause the issue.
Are there anyway to white list facebook request and skip it from the redirect rule ?
Yes, you can detect that Facebook is making a request. You can do this by using the request headers, as explained in the question How to recognize Facebook User-Agent
.
Based on those user-agent strings, you can decide wether to redirect.

HTML/ASP.net/login flow Facebook: how to make redirect URL to my site invisible in address bar ie10

When the user clicks an asp button on my page a redirect to:
https://www.facebook.com/dialog/oauth?client_id={app-id}&redirect_uri={redirect-uri}
will happen. Facebook will then redirect back to my own redirect-uri (with a code). How can I avoid that the user can see this redirect-uri and code in the address bar of the Internet Explorer browser? I think this must be possible because when I redirect to facebook and the user is already logged in then I don't see the url changing to //www.facebook.com/dialog/oauth, facebook redirects immediately back before the uri change gets visible in the address bar of ie. Don't have this issue with Firefox.
If you need to pass some URL parameters in your Facebook return URL, then you can simply do another redirect on your site's landing page to a URL without parameters after you've done the necessary checks.
Of course if you don't need any parameter then just set your FB return URL accordingly to a page without any parameter.

Http referer and bookmark

I'm visiting a website and soon I click on a bookmark in my browser. A new website is opened. My question is:
Does the referer data (which is submitted to the new website) only contain the bookmark info or is my last visited website also within the data?
I'm really not sure about it.
Testing with Google Chrome and Fiddler shows that Chrome doesn't send a Referer header when fetching a page after clicking a bookmark.
An HTTP referrer is only sent if the user arrives from a resource with a URL (generally, another web page). Typing in a URL, clicking on a link in a desktop email program, word document, etc., or opening a bookmark all do not send a referrer, because those sources do not have URLs of their own.
The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from which
the Request-URI was obtained (the "referrer", although the header
field is misspelled.) The Referer request-header allows a server to
generate lists of back-links to resources for interest, logging,
optimized caching, etc. It also allows obsolete or mistyped links to
be traced for maintenance. The Referer field MUST NOT be sent if the
Request-URI was obtained from a source that does not have its own URI,
such as input from the user keyboard.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Note that there is no guarantee that a referrer will ever be sent, even if the source does have a URL.

Resources