0

Ok, i have to build a secure music player; one that don't display music's source (even on the console). I've already built the logic, but, in order to do that, my only way out was to use php header to strem mp3.

My question: is my performance loss "tolerable" doing that:

/main.js

Player.src = "music.php"

/music.php

header('Content-type: audio/mpeg');
header('Content-length: ' . filesize($track));
header('Content-Disposition: filename="sometrack.mp3"');
header('X-Pad: avoid browser bug');
header('Cache-Control: no-cache');
print file_get_contents($track);

instead of that?:

/main.js

Player.src = "music.mp3"

By "tolerable", i mean: 10% loss? 15% loss?

Or Anyone has another suggestion?

Here is the github with the very(!) raw logic: https://github.com/filipemerker/securePlayer

Filipe Merker
  • 2,428
  • 1
  • 25
  • 41
  • 3
    `even on the console` Wrong. It is fundamentally impossible to prevent the user from seeing the content in the Network tab. Give up. – SLaks Jun 22 '15 at 18:23
  • man, i built a token logic that allows me to, yes, show music.php on console, but if you access music.php without the correct token, you will see an error message. (take a look at the github) My question here is about performance not logic @SLaks – Filipe Merker Jun 22 '15 at 18:41
  • "is the performance tolerable" sounds a bit subjective. What tests have you performed so far, and what is the actual, measurable performance difference (if any)? – user700390 Jun 22 '15 at 18:47
  • that is a good observation. Latter i'll edit the question with my test screenshot. @user700390 – Filipe Merker Jun 22 '15 at 18:49
  • @FilipeMerker: All the user needs to do is copy the existing response, or replay the request with the original cookie. (Which Chrome conveniently offers a context menu item to do) – SLaks Jun 22 '15 at 18:56
  • @SLaks: boy, if you read the github files, you'll see that possessing the SAME cookie that played the music once, is useless. Every access asks for a new cookie which is generated at the very moment of the client-side request. Again: my logic is already built and tested (not a noob). Any **performance** tip? – Filipe Merker Jun 22 '15 at 19:01
  • @FilipeMerker: You're still wrong. The user can easily replay the original cookie, since you don't have persistent state on the server. If you do add persistent state, the user can just load the page without JS to get a new valid token. **You can't do this**. – SLaks Jun 22 '15 at 19:12
  • @SLaks: You even have the Flash fallback option, which is widelly used, for example, by extinct Grooveshark and the actual Spotify. If you say that is `fundamentally impossible to prevent the user from seeing the content in the Network tab` that shows you are not aware of the possibilities. (: – Filipe Merker Jun 22 '15 at 19:15
  • @SLaks: Sorry for that, my mistake. The token is generated by server and emmited by client. Every token validation generates a new token. But my logic increases more complexity that makes really hard to hack it. Again, i'm not asking about my logic. I'm asking about php header streaming performance. – Filipe Merker Jun 22 '15 at 19:29

1 Answers1

0

If you have to do it that way, you should consider using readfile instead of file_get_contents

Take a look at PHP readfile vs. file_get_contents.

Community
  • 1
  • 1
JAyP
  • 75
  • 5