Edit: Seems you don’t like to use referrer.
Well, I didn’t really read through all the posts, but I’ll throw in my two cents. It sounds like what would work for you is to check the referring domain. For instance, if they try to directly type in http://www.domain_name.com/get.php?id=123, there’s no referring domain - because it’s typed in directly. In this way, you will display the video only if the user arrives at the page from a link on your site. Does this help?
I don’t want to use referrer checks if possible.
Why?
Because no one that know how it works rely on it. It can just not be trusted.
Let’s say I’m on http://some_site.com and then navigate to http://some_site.com/test.php. I can test to see if the referring domain was “http://some_site.com” like this:
$refering=parse_url($_SERVER['HTTP_REFERER']);
if($refering['host']==$_SERVER['HTTP_HOST']){
echo "all is well";
} else {
echo "all is not well";
}
If they direct type the URL, it will echo “all is not well”. If they arrive at that page from an external source which is not your site, it will echo “all is not well”. But if you arrive at that page from an internal link, it will echo “all is well”. So what’s unreliable about that if that’s the exact behavior you want? Am I missing something?
The referring domain is a user enterable field so anyone wanting to directly access the file directly will just set the referrer to the value that you expect before they make the call.
Setting a session within your page is the only way to ensure that a file is only accessible from that page since only that page has the right session set.
Of course, the referring domain check could just be one of the several checks. It would at least keep 99% of users who don’t know how to enter that variable from accessing it directly or from external links.
However, it doesn’t matter anyway if one person could change this variable on their single browser. This person would have to intentionally do this. But what more would they gain since they could just access it through the site anyway? So actually being able to change the referrer variable on the browser is irrelevant in this case. They can only do it for “their” browser, which does not affect anybody else. And again, they’d gain nothing by changing this variable.
A lot of security software like Norton or Mcafee either strip away HTTP Referer or replace it. That requires zero user intervention. Using HTTP Referer is not going to work. Even proxy servers a lot of users use to hide there true identity and history mess with the HTTP Referer header.
A blank HTTP Referer header must also be accepted because if the user directly enters the address or uses a bookmark there is no HTTP Referer header sent. And again a lot of software strips it away. Second why is the user blocked because they came to your site from another like Google? That just seems insane.
Hmm… first time I’ve heard about Norton and Mcaffe doing this. Sounds like something a virus would do. That’s also the first I’ve heard that obscuring the identity changes the HTTP Referer header. Do you have any references or have you done any tests? I’m not being facetious - I’m really interested in knowing the research on this.
When I clear my history, it doesn’t affect the referrer at all.
Check Google, for more information. This is a well known fact and if you ask a professional programmer that work with webpages about the Refer header, they will say the same.
You can also read up on the HTTP header specs for more information.
So in other words, you don’t personally know - you just heard it somewhere.
I apologize for that last remark. Yes, you can disable referrers and Norton will as well unless you change the security settings.
Hmm… sessions. That brings me to another thought. You can disable cookies too which in this case would render the exact behavior as if you were testing for referrers and they were disabled.
Alright, I hate to submit 4 in a row, but this is a challenge for me. The only thing I don’t know what to do with is the case where they have both cookies and referrers disabled. Maybe in that case, I could compare database logs of ip addresses and times. That would get big fast, so there would have to be some sort of automatic cleanup. But here’s what I came up with so far:
session_start();
function check_referrer(){
$referring=parse_url($_SERVER['HTTP_REFERER']);
//either directly typed or refererrs disabled
if(!$referring['host']){
//Referring host doesn't exist, so check for existing session
if($_COOKIE['lala']==sha1('$LL...//')){
//means they've been on this site recently even though the referrer isn't present
return "all is well";
} else {
//means they haven't been on the site, or they have both refererrs and cookies disabled
return "How do I get around this?";
}
} else if($referring['host']==$_SERVER['HTTP_HOST']){
return "all is well";
} else{
return "all is not well";
}
}
echo check_referrer();
Or you can just forget about trying to protect from direct access… As long as the browser can download the file it will be possible to get the file. Unless you actually have a big problem of users taking all your files and reposting them or whatever. I wouldn’t bother worrying about a non issue until it becomes and issue.
OK this discussion took a lively turn. The more I think about it, I find myself in the “I know anything on the net can be downloaded, but let’s not make it simple for those who want to steal my content”. So, with that said, here’s what I’m thinking:
- caller.php loaded with request for song1.php
- caller.php sets session variable encrypted with known $key with value=song1.mp3 filename
- caller.php immediately calls get.php (without any parameters)
- get.php decrypts session variable with known $key and obtains filename song1.mp3
- get.php DELETES session variable and streams song1.mp3
This should work in most cases:
- Direct call to get.php will result in no file since session not set
- Call to get.php after it is called by caller.php will result in no file since get.php deleted the session variable when called the first time
- mp3 files are stored above webroot so figuring out their location is still not publicly accessible
This breaks if:
- caller.php is loaded and for some reason get.php is not called. In this scenario, session variable is set, and a direct call to get.php (from browser address bar) will start streaming file. I can get around this by forcing an autostart on the flash player so that get.php is called as soon as caller.php gets loaded.
Now I just need to make this work with playlists…i.e., after song1 is played, get.php needs to play song2.mp3 but it won’t since get.php deleted the session after the first song was played.
Still trying to figure it out…does the algorithm above make sense?
Don’t use the referrer. A lot of internet security packages block the sending of referrers the instant you install the software.
Making the player autostart won’t make it much harder. In my case, I just right click a tab in Firefox and disable plugins for that tab. Then I view the page’s source and download the file. In fact, I did that just a week ago on one particular site, and it was very obvious that the link failed after one request. You can say that this requires too much technical knowledge for the casual user, but viewing the source code of a page is already fairly too advanced.
However, there is one thing that you can do to make it a bit harder. You can pass a string or two to your Flash music player, and in the player, a new string will be generated that would be passed to get.php to get the file. Doing that will force the user to invoke the Flash player. (Although decompiling a Flash movie is very easy. There are also still ways to get the file while still invoking the Flash player.)
All decent security software blanks out the referrer header - it is one of the ways that the security software protects the PRIVACY of the software’s owner. It is the exact opposite of something a virus would do since viruses attack the software owner while blanking out the header protects them.
That blanking out the header stuffs up the security on your web site is irrelevant because their security software is working for them and not for you and you’re trying to detect where they came from is the suspect activity that the software is protecting against.
Sessions don’t have to rely on cookies being enabled. The sessionid can be passed in other ways.