Thu, 03 Jul 2008
HTTP Referer
One of our customers subscribes to a library system, which has its users
"authenticated" by verifying the HTTP Referer: header.
So they have to register a single authenticated page, accessible by
their own users only, and we have to put a link to the library system
to that page. Leaving aside the stupidity of such an approach to the
authentication, I have found some interesting facts about the
Referer: header:
Firstly, we have found that going from that page, browsers never send
any Referer: header. When looking into it deeper, we have discovered that when you are on a page retrieved via https, the
browser does not send the Referer: header to the
pages with the http protocol.
So we have decided to write an intermediate redirector application,
accessed over http authenticated by a random string
as a CGI parameter. This application would than redirect user to the final
destination. That also did not work.
The problem was that when redirecting using HTTP 301 status code
(probably 302 as well), the client also does not send the Referer:
header.
The next try was redirect using <META HTTP-EQUIV="Refresh">
tag inside the generated HTML page. Also did not work.
Finally, I have tried to redirect the client using Javascript (rewriting
the window.location parameter in the onLoad
handler), and it worked. So non-Javascript users are out of luck,
but the majority is OK. Still, this system of "authentication" is stupid,
because faking the Referer: header is not hard.
Update - Fri, 04 Jul 2008: MSIE and Referer
Apparently MSIE does not send HTTP Referer: header also when
redirecting using window.location in Javascript. So for now
I have disabled automatic redirection for MSIE, and I am just displaying the
text "Use firefox or click to the above link manually.". In the meantime,
I have found a really comprehensive guide on browser type detection.