About Nginx's x-accel-redirect response
Read a number of articles on the Internet, all say can be used to control the file download permissions.
The principle is that when accessing download.php, the header is verified ("X-accel-redirect: Target File").
But I have a question, if I know the real file name and storage path of the target files directly after access, it is not bypassing the x-accel-redirect?
As an example:
Assuming that the target file is actually stored in Http://www.1.com/download/123.xls
and on the website page has the download link http://www.1.com/download.php?file=xxxx
Then this link allows permission control, but what if I enter Http://www.1.com/download/123.xls directly to access it? Did you bypass permission control?
Share to: more
------Solution--------------------
In Web applications, there are often files that need to be downloaded. If these files are very private and are downloaded directly from the Web server, you cannot check the file's download permissions. In the past, it is necessary to use the program language to read the file and output it, so that the permission problem can be solved by using the program language to determine the permissions. However, the use of program language to read the file is also a problem of efficiency, if the file size is larger or download concurrent number is large, the server quickly overwhelmed.
Based on this scenario, the Web server software provides the appropriate workaround: Use a response header to control the download. Currently, squid, Apache, lighttpd, Nginx and other HTTP server support this way, but their response header name is different:
Nginx:x-accel-redirect
Squid:x-accelerator-vary
Apache:x-sendfile
Lighttpd:x-sendfile/x-lighttpd-send-file
Using the response header to control the download principle is similar:
When a client initiates a request to download a file, because it does not have a X-accel-redirect header, the Web server does not immediately output the file to the client, but instead gives the request to the backend program language, which the program language verifies that the client can download the file. Writes the corresponding X-accel-redirect header and ends the processing; when the X-accel-redirect header returns, it passes through the front-end Web server, and the Web server checks the header before outputting the file to the client.
So, what if the client forges a x-accel-redirect header to read? Of course, it is not possible to download, because the Web server only know the backend sent to the X-accel-redirect header, the client sent not counted.
So the following is the use of nginx to achieve the above process:
1, change the directory permissions, the client initiates the request, the request of this directory to the backend
location/mp3/{
alias/data/html/mp3/;
Internal
Error_page 403 =200 @backend;
}
Location @backend {
Proxy_pass http://www.sudone.com;
}
This way, when a user accesses an address such as Http://www.sudone.com/mp3/1.mp3, they will not be able to download the file, and Nginx will submit the request to the backend server.
2. Configure a rewrite on the backend server
Rewrite "^/mp3/(. *) \.mp3$"/read_file.php?id=$1 last;
The purpose of this rewrite is to point the request Http://www.sudone.com/mp3/1.mp3 to a PHP programming language, which is handled by the programming language.
3, write a PHP program to determine the permissions
Files can be downloaded within the time limit (19 to 23 o'clock):
$hour =getdate () [hours];
if ($hour >=19 && $hour <=23)
{
Header ("Content-type:application/octet-stream");
Header ("X-accel-redirect:/mp3/". $id. ". MP3 ");
}
?>
Every night from 19 to 23, the address will output X-accel-redirect header, the content is the file address. After the output X-accel-redirect header, the file can be downloaded, otherwise the client will not get anything. So it is possible to download the file from 19 o'clock to 23 in the evening, and no other time period.
In this way, the configuration is complete.
I also tried to configure a, PHP is to re-forward the request, just to the last step when the server reported 404 errors, has been unable to find the reason. Do not know whether it is related to the version, the Nginx version of his own version of the information was changed by me, so I can not find the revision number.
