I found two minor spelling mistakes:
-README file on line 80 it says 'gaurantee'
-lang/de_DE.php on line 17 instead of 'Neimals' it should be 'Niemals'. Also the lang key is 'en_US' instead of 'de_DE'.

Keep up the good work ;-)

Thanks! The GitHub master has been updated with your fixes

https://github.com/hamishcampbell/silverstripe-securefiles

Hamish, Thank you very much for this module, this is really, really great.

I have one question, I think I know thew answer but since I am not really deep into coding, I just need to make sure I am going down the right track.

Everything is working as advertised with the module. One question I have is, how do you make sure you cannot browse the file?

Use Case:
I have some MP3s in folder assets/music. When I use the audio page type, you can only play the file if you are authorized to access the file. So, works perfect. Further more if you put in the url, mysite/assets/music/song.mp3 it cannot be viewed either. However, once I log in, I can actually download the file. What I need to figure out is how to only allow the file access through SS only.

I am trying to allow users the ability to listen to songs only through the audio interface and not be able to see or download the mp3 file.

Now, I am thinking this is on the web-server side. Would this be correct?

DM

Hey David,

This is difficult to achieve because in order to listen to an audio file the browser has to download it (in some form).

I'm not sure what you mean by an Audio Page Type, you might have to share the code that is used to stream the audio to the browser.

One way to make it more difficult (but certainly not impossible) to download the file directly would be to also use the token access decorator to produce a 'one time only' access for each request. Rig your player so it gets that unique URL. That means that the player can load the mp3 once, but attempting to use that URL to download the file a second time will fail.

This is only a stop-gap solution though. The problem you're describing is really around DRM and streaming audio, which is a hugely complex subject.

Regards

Hamish

This is part of the functionality from UC. Nothing I did, just seeing what I can do with what is out there.

http://www.leftandmain.com/silverstripe-screencasts/2010/08/23/filedataobjectmanager-media-features/

As far as the content, I just wanted to make sure that you could not access the mp3 directly through the url, but through SS only.

If you look at the source source it show where the SWF player is pulling the file from. Then they just have to put in the full url with the file name and they can download it directly. That is the part I am trying to avoid.

Yea, I know this is difficult, but thought I would ask the smart guys here before I started off and maybe reinvent the wheel.

Thanks again for your hard work and your sharing.

DM

Thanks David

Yeah, it's difficult because the player simply tells the browser where to get the file from, then the browser downloads it so it can play it. As far as SilverStripe is concerned, there isn't much difference between the browser streaming the file and a user downloading it.

I think my first suggestion is going to be your best bet - you'll need to add some smarts to tell Secure Files to generate a token for access and it won't prevent a determined user from downloading the file, but it should at least raise the barrier slightly higher.

I can't think of a better solution that doesn't rely on media streaming services or DRM.

First tests look pretty good. I added Options -Indexes to the .htaccess file. I will further test, but IE will not download the file and it looks like Firefox will download the file, but then corrupts it where it won't play. (When playing it in Winamp it accelerates the mp3 and doesn't play it, i.e. a 4 minute song plays in about 30 seconds with now sound).

I will test some more and determine if the change in .htaccess really did do anything, but initial tests look good.

The -indexes did not have any impact on the module. Looks like the module is protecting the data rather well. And it is difficult for anyone to access the data directly through a url patch.

Once again Hamish, nice job.

DM