auth_request|access|auth_basic比較
無論是通過access模塊限制IP還是通過auth_basic模塊限制用戶名密碼，這些都是非常簡單的用戶驗證方式。
在生產環境當中很可能會有動態web服務器，它們通過更加複雜的用戶名密碼權限驗證。這個時候可以通過訪問nginx資源時候，先將用戶的去請求傳遞給這樣的應用服務器，根據應用服務器返回的結果再判斷請求資源能不能繼續執行。在access階段有一個auth_request模塊，該模塊就可以完成這樣的功能。
可以通過合理配置Nginx的auth_request模塊來實現對敏感路徑下的內容進行訪問限制（通過auth_request來進行的權限限制）。該模塊默認是不會編譯到Nginx中的需要手動添加--with-http_auth_request_module
auth_request原理語法
原理：收到請求後，先將該請求hold住，生成子請求，子請求和該請求內容是相同的。通過反向代理技術把子請求傳遞給上游服務，根據上游服務的響應再來決定是否處理當前的請求。
功能：向上遊的服務器轉發請求，若上游服務器返回的響應碼是2XX，則繼續執行，若上游服務器返回的是401或者403，則將響應返回給客戶端。
Syntax: auth_request uri | off; --加上url會生成一個子請求，這個子請求會訪問該url，根據該url返回的結果來決定是否允許該請求向下繼續執行
Default: auth_request off;
Context: http, server, location
Syntax: auth_request_set $variable value; --根據返回的結果設置變量來做進一步處理
Default: —
Context: http, server, location
舉個例子如下
服務器A(192.168.179.99)，其路徑/上存有敏感信息，其他路徑可公開訪問。
服務器B(192.168.179.100)，爲認證服務器，其上部署了本項目代碼。
服務器A(server1)的Nginx配置文件：
location / {
auth_request /test_auth; --生成子請求會去訪問/test_auth
}
location = /test_auth{
proxy_pass http://192.168.179.100/auth_upstream; --反向代理到後端auth_upstream
proxy_pass_request_body off;
proxy_set_header X-Original-URI $request_uri;
}
[root@localhost ~]# echo "proxy back this is 192.168.179.99" > /usr/local/nginx/html/index.html --該條記錄用來驗證用戶在後端192.168.179.100返回狀態
（1）服務器B(server2)的Nginx配置文件：
server{
listen 80;
access_log logs/host.log main;
charset utf-8;
location /auth_upstream{
return 200 'auth success';
}
如果用戶爲合法用戶：
那麼服務器B將會生成session，並通過Set-cookie命令告知用戶瀏覽器。用戶通過此Cookie即可獲得服務器B的認可授權。當用戶通過此Cookie訪問服務器B中的/auth_upstream目錄時，會返回200的狀態碼。
（2）服務器B(server2)的Nginx配置文件：
server{
listen 80;
access_log logs/host.log main;
charset utf-8;
location /auth_upstream{
return 403 'auth success';
}
}
如果用戶爲非法用戶：
那麼服務器B將不會session，由於用戶無法獲得認可的Cookie，那麼當用戶再次訪問/auth_upstream的路徑時，服務器會返回403錯誤。
總結
以上，通過auth_request模塊以及相關配置就實現了對敏感內容的訪問限制。而且通過第三方的機制，也無需自己手工實現登錄功能。同時，此方案可以對同一域名下的不同子域名中的內容進行訪問限制。可以重複利用一個登錄系統，服務於多個其他系統。（auth_request模塊對於我們擁有一個統一的用戶健全系統是非常有用的）