I have decrypted my audio file, I now want to play it and then unlink it.
What I currently have is:
<?php
$destination = "/tmp_upload_dir_copy/test.mp3"
header('Content-Type: audio/mpeg');
readfile($destination);
unlink($destination);
?>
Anyone have any ideas what I'm doing wrong or what else do I need?
maybe I need to use fpassthru() ?
PHP works only server side. You can only guarentee the file is SENT to the client, but there is no way to directly make sure it has been PLAYED by the client.
Setting the header will only influence how the browser treats the data (in this case the browser is informed the data is audio). Chrome, for example plays audio files but some browsers may give users a download prompt.
You'll need client side software, like a audio playing component (search "Flash MP3 player") to embed in a page to play the audio file.
Sounds like you don't really want to delete the file immediately, as any number of things could go wrong on the user's end between downloading the mp3 and actually playing it. The user might need to initiate the file transfer again in many cases. Instead you might want to set up a cron job that runs every night and deletes the mp3 files that are more than one day old. (Also, I'm not sure what you meant by "decrypt" the audio file.)
Related
I have a php site I am developing, I uploaded some audio files into a folder on my server and saved their location URL on my database, now I want to call up the audio file in one of my pages and stream it, my major problem here is the line of code I can use to stream out, and let it be functional on mobile browsers as well. thanks as you help me out.
On the PHP side, something like this should work - assuming you refer to mp3:
header('Content-Type: audio/mpeg');
header('Content-length: ' . filesize('/path/to/your/file.mp3'));
print file_get_contents('/path/to/your/file.mp3');
On the front-end you will then need to look for a Javascript based solution that will actually play the file. You said, it needs to be cross-platform - that's more a front-end (Javascript) challenge than something that can be controlled by PHP.
So, i want to do some metrics about the times one image is open, i need to give my users the link of the image but i need to track how many times they open it.
If i give them the link like http://webserver.com/image.png i cant track how many times the images is opened, so i think if i can make a PHP script who streams the binary data when the user calls the link like http://webserver.com/image.php, it maybe works.
In this scenario, i can simple write a metric script to store information like ip and time, but i don't know how to echo the image in order to show it on the browser. I think that maybe if i open the image in binary mode from the PHP script and then stream that information to the user it will work, but in this area i know nothing.
Some people can say that i can simple do an echo("image.png"); at the end of the script but this won't work if you think a little more.
Generally, you will want to tell the browser what type of content to expect, and then send the bytes of the content. For example:
incrementHitCounter();
logIP();
// Dear browser, a PNG file is coming your way
header("Content-Type: image/png");
// here it is
readfile("/path/to/image.png");
http://php.net/manual/en/function.header.php
http://php.net/manual/en/function.readfile.php
I know this question is silly.
But as per our intelligent Client request, I am not able to answer his question. Any one help for this.
We are building a online tutoring site. where it contains pdf, .ppt, .doc formats files are uploaded for reading as course materials. His (Client) request is that user can read all the contents but they must not download the materials and use this.
That is all the documents must be opened in their browsers.
Is it possible? Any other ideas?
Any other ideas?
Explain to your client that the only way for a document to appear on a user's computer screen is for the document to exist on that user's computer.
In other words, viewing a document involves downloading it. Even supposing the software on the user's computer somehow makes it impossible for the user to directly manipulate an electronic copy of the material, the user can take out a digital camera and take a picture of the screen.
There are ways to make it difficult for the user to save a copy of the file. However, it's likely that this will do more harm (frustrating users) than good (preventing theft).
Some users may want to peruse the material at times when they do not have an internet connection, or may want to copy it onto their mobile device (for instance), but accessing the internet on their mobile device is expensive so they would like to do the download on their computer.
If you send the data to the client the client has effectively downloaded it. You can make this difficult, but not impossible.
The only sure way to prevent downloading is to prevent viewing.
If this is a copyright problem it should be solved with legalese, not software.
Here are some guide-lines you may consider:
Don't put direct link of files such as:
Download
Instead, try to generate your pdf dynamically or put a another encrypted medium for
downloading eg:
Download
2: Don't allow directory browsing, use htaccess file with following commands:
Deny from ALL
3: Not sure, but you may possibly allow file opening this way too:
$filename="/path/to/file.jpg"; //<-- specify the image file
if(file_exists($filename)){
header('Content-Length: '.filesize($filename])); //<-- sends filesize header
header('Content-Type: image/jpg'); //<-- send mime-type header
header('Content-Disposition: inline; filename="'.$filename.'";'); //<-- sends filename header
readfile($filename); //<--reads and outputs the file onto the output buffer
exit; //and exit
}
Note: above is just an example of image not pdf but you can modify it for your needs.
An online site does not necessarily mean it is a web site. You could write a custom client that accesses the data and displays it.
The data would need to be encrypted between the client and the server. It probably should not be sent 'in bulk' either.
The effort associated with developing that is prohibitive.
You could license the software that allows users to read books, page by page, that is part of the Safari Books Online web site.
As best I can tell, they take the pages that they are going to display and turn them into small images. These images look as if they are sent in a random order, and assembled by the browser via javascript.
These tactics won't stop a determined person from getting your clients content... but the effort is unlikely to be worth it.
You could put the docs into Google docs and embed the docs viewer into your site. Of course, there's no stopping people from taking screenshots, copy/pasting text, downloading HTML, etc.
What do you mean by "read" but not "download"?? Do you know that even if you disable cache (which by itself is a bad idea) won't restrict an eaaaasy right-click>view source, "save target as", etc.?
I mean, the best you can have is a flash reader that is harder to save the content from, and that means disabling selection and copying, but anyway, it doesn't forbid anything.
The only way to forbid download is to return HTTP 403 :)
I'm building a streaming video site. The idea is that the customers should pay for a membership, login to the system, and be able to view the videos. I'm going with FlowPlayer for showing the actual videos.
The problem now is, the videos need to be stored somewhere publically and the url to the .flv files needs to be passed to flowplayer for it to be able to show them. This creates a problem because anyone can do a view source, download the video, and distribute it all across the internet.
I know some people serve images using php by doing an image header() and then they can do something like:
<img src="image.php?userId=1828&img=test.gif" />
The php script validates the user ID and serves up the .gif and the actual url of the gif is never revealed.
Is there anyway to do this with .flv or any other video format also? E.g, the file and user ID passed onto the PHP script, it validates them, and returns the video?
You can set up a directory containing the FLV files on your webserver that can only be accessed by PHP, then in your PHP script you can authenticate the user as usual and simply send a header to the browser telling it to expect an FLV, then echo the raw FLV data:
<?php
// here is where
// you want your
// user authentication
if ($isAuthenticated)
{
header("Content-type: video/flv");
echo file_get_contents($pathToFLV);
}
?>
As Chad Birch discussed, this will only prevent people from linking directly to the video - you can't prevent piracy this way.
The short answer is that no, you're never going to be able to prevent people from downloading your videos if they want to. There are various ways to make it trickier for them to do it, but there's no foolproof method. You're hitting what is basically the entire problem with DRM - you can't show someone your content without giving it to them unencrypted at some point, and if they can view it, they can rip it.
Since your flv player is a flash application, it will always be possible to download and decompile it. When decompiled the actual url to the flv will be visible. So it won't really make any difference if you are using direct url's to the flv movies or something like you described in your question
<img src="image.php?userId=1828&img=test.gif" />
Please google the word Pseudostreaming you will get the answer
There are some servers like lighttpd which has inherent support for flv streaming....
I hope you will get the answer.........
Apache with mod_flvx module also has similar effect like lighttpd.
I have a website that plays mp3s in a flash player. If a user clicks 'play' the flash player automatically downloads an mp3 and starts playing it.
Is there an easy way to track how many times a particular song clip (or any binary file) has been downloaded?
Is the play link a link to the actual
mp3 file or to some javascript code
that pops up a player?
If the latter, you can easily add your
own logging code in there to track the
number of hits to it.
If the former, you'll need something
that can track the web server log
itself and make that distinction. My
hosting plan comes with Webalizer,
which does this nicely.
It's a javascript code so that answers that.
However, it would be nice to know how to track downloads using the other method (without switching hosts).
The funny thing is I wrote a php media gallery for all my musics 2 days ago. I had a similar problem. I'm using http://musicplayer.sourceforge.net/ for the player. And the playlist is built via php. All music requests go to a script called xfer.php?file=WHATEVER
$filename = base64_url_decode($_REQUEST['file']);
header("Cache-Control: public");
header('Content-disposition: attachment; filename='.basename($filename));
header("Content-Transfer-Encoding: binary");
header('Content-Length: '. filesize($filename));
// Put either file counting code here, either a db or static files
//
readfile($filename); //and spit the user the file
function base64_url_decode($input) {
return base64_decode(strtr($input, '-_,', '+/='));
}
And when you call files use something like:
function base64_url_encode($input) {
return strtr(base64_encode($input), '+/=', '-_,');
}
http://us.php.net/manual/en/function.base64-encode.php
If you are using some JavaScript or a flash player (JW player for example) that requires the actual link of an mp3 file or whatever, you can append the text "&type=.mp3" so the final link becomes something like:
"www.example.com/xfer.php?file=34842ffjfjxfh&type=.mp3". That way it looks like it ends with an mp3 extension without affecting the file link.
Use your httpd log files. Install http://awstats.sourceforge.net/
Use bash:
grep mp3 /var/log/httpd/access_log | wc
If your song / binary file was served by apache, you can easily grep the access_log to find out the number of downloads. A simple post-logrotate script can grep the logs and maintain your count statistics in a db.
This has the performance advantage by not being in your live request code path. Doing non-critical things like stats offline is a good idea to scale your website to large number of users.
You could even set up an Apache .htaccess directive that converts *.mp3 requests into the querystring dubayou is working with. It might be an elegant way to keep the direct request and still be able to slipstream log function into the response.
Is the play link a link to the actual mp3 file or to some javascript code that pops up a player?
If the latter, you can easily add your own logging code in there to track the number of hits to it.
If the former, you'll need something that can track the web server log itself and make that distinction. My hosting plan comes with webalizer, which does this nicely.
Is there a database for your music library? If there is any server code that runs when downloading the mp3 then you can add extra code there to increment the play count. You could also have javascript make a second request to increment the play count, but this could lead to people/robots falsely incrementing counts.
I used to work for an internet-radio site and we used separate tables to track the time every song was played. Our streams were powered by a perl script running icecast, so we triggered a database request every time a new track started playing. Then to compute the play count we would run a query to count how many times a song's id was in the play log.
The problem I had with things like AWStats / reading through web server logs is that large downloads can often be split in data chunks within the logs. This makes reconciling the exact number of downloads quite hard.
I'd suggest the Google Analytics Event Tracking, as this will register once per click on a download link.