11

We use the URLReferrer and a code passed in on the query string to produce online videos so that only our paid clients can link to our video playback page. This system has worked well for some time. I know the URL referrer can be spoofed, but who would tell their clients to do such a thing to access a video ? It's worked well for us.

However, today I was asked about someone for whom it did not work. The URLReferrer is null, and their site is HTTPS. I have done some reading online and I get the impression there's no way to access the URL referrer when the source page is https. Is this correct ? If I made a https version of our site, would that resolve it ? Or is there any other way for me to get around this ?

Thanks

Abel
  • 56,041
  • 24
  • 146
  • 247
cgraus
  • 784
  • 2
  • 9
  • 26

1 Answers1

13

Your online research is correct. The main reason for not setting an HTTP Referrer header or equivalent is that this could be a security issue. The referrer contains "where you come from", this is private information, and should not be exposed to others, what use is it otherwise to have a secure site if everyone can track where you have been?

So: you cannot get the referrer if the referrer is encrypted (with SSL or otherwise).


Update: here's what the HTTP specification says about coming from a secure site:

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

As you might have guessed, there's no way around this restriction. Your only option is to use a different verification model. One such method is giving your users a key and require them to send that as a parameter with the request. Several other methods can be thought of.

Abel
  • 56,041
  • 24
  • 146
  • 247
  • Thanks - the issue with the key is simply that someone could then copy the link off their page and use it, this is what we're trying to avoid. As it's a video, the obvious solution is to only allow them to embed the video in their own page, and not link to our playback page. – cgraus Jan 13 '12 at 21:48
  • Already +1'd, just to be picky, you're quoting the HTTP spec, not the [HTTPS spec](http://tools.ietf.org/html/rfc2818) ;-) – Bruno Jan 13 '12 at 23:06
  • @Bruno: you're right, I wasn't paying enough attention. Fixed. – Abel Jan 13 '12 at 23:56