通过PHP请求特定音频文件的方式是否比这更少？

Question

I need an audio file from the output of a php script to be placed into the source of a HTML audio tag. I can't specify which as I can't add POST variables so I do so by setting the SESSION "songRequested" through an ajax call and then requesting the file and using the session variable to specify which file is necessary.

HTML

<audio id ="player">
    <source src="" id = "source">
</audio>

JS

$.post('includes/songrequest.php',{'request':songName},function(){
$('#source').attr("src","includes/songrequest.php");
    player.load();
    player.play();
});
//Declare the session variable as the file you want and set the audio source to be the songrequest php below with the session variable as the file to be downloaded.

PHP

<?php
session_start();
if(!isset($_SESSION['u_uid'])){
    exit(); 
}
if(isset($_POST['request'])){
    $_SESSION['request'] = $_POST['request']; 
    //If requesting with post variables, set the session variable to it.
    exit(); 
}
//Otherwise, retrieve the file set as the session variable
$file = dirname(getcwd(),2)."\\users\\".$_SESSION['u_uid']."\\".$_SESSION['

header('Content-Type: audio/'.pathinfo($file,PATHINFO_EXTENSION));
header('Cache-Control: no-cache');
header('Content-Transfer-Encoding: binary');
header('Content-Length: ' . filesize($file));
header('Accept-Ranges: bytes');
readfile($file);

I had to go with this as I couldn't pass post variables when I called for a php source in the audio tag and I don't know of a way to really handle audio data natively in javascript.

Answer 1

Rally there is nothing more secure about post then a get request. Both can be spoofed against your site. The best way to do it if you ask me is to not use either of them, but instead use a URI segment. I should mention this is no more secure then either post or get the main advantage of a URI is you can still use the get and post data without muddling it up. And when you think about it, logically it is a resource you are identifying, so using just a URL/URL makes a sort of sense there.

URI is the part of the URL that is after the "real" resources location. An example would be

$('#source').attr("src","includes/songrequest.php/{songname}‌​");

Where {songname} is the request URI. This is commonly used in MVC frameworks that pipe everything through a main index.php. Such as www.example.com/index.php/some_controller/some_method. Often this is fact is hidden by rewriting the URL with mod_rewrite ( HTACCESS ).

Now to access that data you can look in the $_SERVER Super Global, where it should be something like $_SERVER['PATH_INFO'] ( I forget off the top of my head ). You may have to trim some slashes off or clean it up a bit..

Now as to the content of that data. I would suggest not even passing a filename, just a hash or ID or songname etc. Then you use that to look up the actual path. This will prevent paths being used that you don't want, as the path comes from an internal data source that is looked up by that "piece" of data you are passing.

So you would pass something like this ( if using a pretty hash )

$('#source').attr("src","includes/songrequest.php/2Bzi0U8t");

Then you look up that value in the DB, get the URL and off you go.

Also I don't think there is anything inherently wrong with just doing this

$('#source').attr("src","includes/songrequest.php?song=2Bzi0U8t");

The key here is to not pass an actual path, because that could be exploited by directory transversal. Which, is where a hacker supplies something like this as the path

song=../../../somefile_we_dont_want_a_hacker_accessing.txt

Basically it allows them to navigate around on the file system and access things they shouldn't be accessing. But by using a lookup for that the worst they could do is lookup something already stored in your DB.

Make sense.