Speaking of access permission control, many of them read nginx-related Article Friends will naturally think of the X-accel-redirect header. This header has a defect, that is, all access requests will first pass through a FastCGI to determine the permission. In the download system, this method is very suitable, but on the image server with a very large access volume, simply using this method will make a large number of images without permission judgment go through a FastCGI process, in this case, it consumes a lot of resources for no reason. Although X-accel-redirect is a new solution, it does not mean it can solve all problems well, and it does not prevent you from continuing to think about other solutions.
The image server and permission judgment are mainly used for systems such as blogs and albums. On the Internet, we can see that most of the current blogs, albums, and other systems do not have permission judgment on the images themselves, but only control the permissions of some webpages. In this case, many netizens lock their images. In fact, this image can still be opened externally. I guess one of the reasons is that there are performance problems in implementation, and the other is that many websites place images on CDN, but CDN does not have a corresponding solution for this. I walked around and found that only the QQ space is using images with permissions, and it looks like it is implemented directly with FastCGI, and the performance is not bad. I admire it.
The following is a simple solution to the performance problem. The idea is to place a control file near the access image and determine whether to pass FastCGI Authentication through nginx. The principle is similar to Apache's. htaccess. It is useful to CDN because most CDN services are squid. You need to add the Squid cache clearing mechanism.
1. Single Image Control
If the image is placed according to the hash structure, you need to add a control file to each image after locking the image. If there are many images for this user, it is slightly less written.
For example, there is a graph:
/Data/image/A/z/asdfqerqwegasd.jpg
Write an empty file:
/Data/image/A/z/asdfqerqwegasd.jpg. Lock
Then judge in nginx Configuration:
Location /{
Root/data/image /;
If (-F "$ {request_filename}. Lock ")
{
# Rewrite ^ (. *) $ http://www.sudone.com/access.jsp? Url = $1 last;
Return 403; # Test
}
}
In this way, as long as there is one next to the image. the lock file will access 403 forbidden. Using rewrite, the image links and cookies will be located at the backend, the backend returns the judgment result X-accel-redirect header or redirects to another JSP to fill in the password.
2. Directory Control
If the image is placed by directory, the configuration will be slightly more complex.
Location /{
Root/data/image /;
If ($ request_filename ~ ^ (. *)/[^/] * $ ){
Set $ dir $1;
}
If (-F "$ {dir}/lock ")
{
# Rewrite ^ (. *) $ http://www.sudone.com/access.jsp? Url = $1 last;
Return 403; # Test
}
}
First, use the regular expression to retrieve the directory of the image path, and then use the control file name to determine whether the file exists, in this way, you only need to place an empty file named lock in the image directory to control the entire directory:
/Data/image/A/z/lock
Test, the effect is good. As long as the control file exists, access is immediately 403; Delete the control file and access is normal.