X-Accel-Redirectresponse of NGINX has read several articles online, all of which are used to control file download permissions. The principle is to verify the permission when accessing download. php. if the permission is passed, the header (X-Accel-Redirect: & nbsp; target file) is used ). However, if I know the actual file name and storage path of the target file and access it directly, it does not bypass X-Accel-Redirect response of NGINX.
I read several articles on the Internet, that is, they can be used to control file download permissions.
The principle is to verify the permission when accessing download. php. if the permission is passed, the header ("X-Accel-Redirect: target file") is used ").
However, if I know the actual file name and storage path of the target file and then access it directly, isn't it bypassing X-Accel-Redirect?
For example:
Assuming the target file is actually stored in the http://www.1.com/download/123.xls
And there is a download link http://www.1.com/download.php on the website page? File = xxxx
You can use this link to implement permission control, but what if I enter http://www.1.com/download/123.xlsdirectly? Didn't I bypass permission control?
Share: More
------ Solution --------------------
In web applications, files are often downloaded. If these files are private and downloaded directly on the web server, you cannot check the file download permission. In the past, when permissions were required, the application language was used to determine the permissions, and the program language was used to read and output the files. This solved the Permission problem. However, using the program language to read files brings about efficiency issues. if the file size is large or the number of concurrent downloads is large, the server will soon be overwhelmed.
Based on this situation, the web server software provides the corresponding solution: Use a response header to control the download. Currently, http servers such as squid, apache, lighttpd, and nginx support this method, but their response header names are different:
Nginx: X-Accel-Redirect
Squid: X-Accelerator-Vary
Apache: X-Sendfile
Lighttpd: X-Sendfile/X-LIGHTTPD-send-file
The principle of using response header to control downloads is similar:
When the client initiates a request to download a file, because there is no X-Accel-Redirect header, the web server does not immediately output the file to the client; instead, the request is sent to the backend program language. The program language verifies that the client can download the file, write the corresponding X-Accel-Redirect header, and end the processing; the X-Accel-Redirect header is returned by the front-end web server. the web server checks this header before outputting the file to the client.
What if the client spoofs an X-Accel-Redirect header to read the data? Of course, it cannot be downloaded because the web server only recognizes the X-Accel-Redirect header sent from the backend.
So we will use nginx to implement the above process:
1. change the directory permission. when the client initiates a request, all requests for this directory are sent to the backend.
Location/mp3 /{
Alias/data/html/mp3 /;
Internal;
Error_page 403 = 200 @ backend;
}
Location @ backend {
Proxy_pass http://www.sudone.com;
}
In this way.
2. configure a rewrite on the backend server
Rewrite "^/mp3/(. *) \. mp3 $"/read_file.php? Id = $1 last;
The purpose of this rewrite is to forward the request http://www.sudone.com/mp3/1.mp3to a PHP language, which is processed by the language.
3. write a php program to determine permissions
For example, you can download an object from to within the specified time:
$ Hour = getdate () [hours];
If ($ hour >=19 & $ hour <= 23)
{
Header ("Content-Type: application/octet-stream ");
Header ("X-Accel-Redirect:/mp3/". $ id. ". mp3 ");
}
?>
The X-Accel-Redirect header is output every night from to. the content is the file address. After the X-Accel-Redirect header is output, the file can be downloaded. Otherwise, the client cannot get anything. So we can only download files from PM to PM. other time periods won't work.
In this way, the configuration is complete.
I tried to configure it myself. PHP re-forwarded the request, but at the last step, the server always reported a 404 error. No reason was found. I don't know if it has something to do with the version. I have changed the nginx version I installed, so I cannot find the version number.
