ansaurus

Question

Answer 1

A:

Disable firewalls, and anti-virus /or anti-spyware checking and see if that helps. I know this may sound trollish, but I've personally seen many instances where the problem miraculously disappeared when this advice was taken.

They tend to have an overzealous idea sometimes of what "Secure" is, and break browser behaviour in the progress. ( If you have AVG and have problems with email ( pop3 ), turn off AVG and watch email magically return to working status )

Kent Fredric 2008-12-31 01:54:24

If you read the linked kb article you would see that this is a known issue with IE, not influenced by other software.

Sparr 2008-12-31 03:05:10

Ah, no, the kb article complains about crossing security boundaries, its clear from the OP that the problem even occurs on same-level securities, and I have, from experience, seen AV software tamper with and cause this behaviour!

Kent Fredric 2008-12-31 03:08:57

( I *have* used referrers in IE, in bare http:// *and* had them work, so I'm not exactly making this up .. )

Kent Fredric 2008-12-31 03:13:25

I cannot imagine worse advice that just disabling your entire security insulation across the board to "see if that helps". I *have* had problems with AVG email protection with an SSL POP3 account, for which I turned of the email filter, not *all* AVG protection.

Software Monkey 2008-12-31 09:22:20

I'm not saying leave it off permanently... and besides, its is only an **illusion** of security 99% of the time. If you're only browsing your own content, I **hardly** think you're likely to get hit by ActiveX controls on your own pages.

Kent Fredric 2008-12-31 19:35:10

Answer 2

+2 A:

You may want to use a different mechanism anyway. Referrers are easily spoofed. Checking referrers really isn't a good security solution, and if they're going to cause you headaches like this, maybe you want to find another way.

For example, the server generating the first page could add an authorization token to the URLs to the second server, and the second server could check that the tokens are valid. This way, all of the details are under your control, and the only browser behavior you're counting on is that the full URL is sent to the second server.

Ned Batchelder 2008-12-31 02:08:01

actually, i forgot to mention this part but it is using authorization tokens, Every url has the proper auth token appended to it.

willz 2008-12-31 19:14:21

if you already have an auth token, then why bother with referrer checking at all?

Ned Batchelder 2008-12-31 19:40:35

Answer 3

+4 A:

How are you "getting to" the file in question?

IF YOU ARE USING JAVASCRIPT to get to the file, IE WILL FAIL.

IE has had a major bug since the dawn of time on this.

e.g. document.location.href = 'myNewPage.html'; //FAILS to pass referer in IE

Bug #421 over on Web Bug Track

won't be fixed in IE8 either! :-(

scunliffe 2008-12-31 02:17:52

its just a plain html anchor tag. no javascript.

willz 2008-12-31 19:15:00

Answer 4

A:

I have resolved, include this code in all page, in your project

session_start();
if($_SERVER['SERVER_PORT'] == 443 )
 $http = 'https://';
else
 $http = 'http://';

$adress = $http.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; 

$_SESSION['referer'] = $_SESSION['current_page'];
$_SESSION['current_page'] = $adress;
$_SERVER['HTTP_REFERER'] = $_SESSION['referer'];

Sorry for my bad English ....

2009-06-01 09:31:10

Answer 5

A:

I'm not using IE7 so I can not check this.. but I guess this should work without problems:

<script type="text/javascript">
      document.location= "www.your-server.com/your_page.html?referrer=" + document.location.href;
</script>

And than on the the second server you can check the value of the referrer parameter instead of relying on whether browser sends the referrer or not.

2009-06-21 13:41:21

ansaurus

tags:

views:

answers:

Internet Explorer http referer issue

related questions