過去兩天裡，我解決了乙個非常有趣的問題。我用乙個nginx伺服器作為**，需要能夠向其中新增乙個認證層，使其能夠使用外部的認證源（比如某個web應用）來進行驗證，如果使用者在外部認證源有賬號，就可以在**裡認證通過。
需求一覽
我考慮了幾種解決方案，羅列如下：
很顯然，給整個系統新增額外請求將執行的不是很好，因為這將會增加延遲(特別是給每乙個頁面檔案都增加乙個請求是很讓人煩惱的).這就意味著我們把subrequest模組排除在外了。python/flash解決方案好像對nginx支援的也並不好，所以咱也把它排除了。就剩lua了，當然nginx對原生化支援得不錯的。
因為我不想再擴充套件的伺服器上對每乙個請求都做認證，所以我決定生成一些令牌，這樣人們就可以將它儲存起來，並把它呈現給伺服器，然後伺服器就讓請求通過。然而，因為lua模組沒有一種保持狀態的方式(我已經發現)，所以我們不能將令牌隨處儲存。當你沒有更多的記憶體時，怎樣來驗證使用者所說的話呢？
解決問題
加密簽名的方式可是咱的救星！我們可以拿使用者的使用者名稱和過期時間資料來給使用者新增簽名的cookies，這樣就能很容易的驗證每個使用者是誰了，同時我們就不用令牌了。
在nginx中，我們要做的就是直接在指定位置配置access_by_lua_file /our/file.lua，這樣這個指定位置就可以保護我們的指令碼了。現在，讓我們一起來寫**：
複製** **如下:
-- some variable declarations.
local cookie = ngx.var.cookie_mytoken
local hmac = ""
local timestamp = ""
local timestamp_time = 0
-- check that the cookie exists.
if cookie == nil or cookie:find(":") == nil then
-- internally rewrite the url so that we serve
-- /auth/ if there's no cookie.
ngx.exec("/auth/")
else
-- if there's a cookie, split off the hmac signature
-- and timestamp.
local divider = cookie:find(":")
hmac = cookie:sub(divider+1)
timestamp = cookie:sub(0, divider-1)
end-- verify that the signature is valid.
if hmac_sha1("some very secret string", timestamp) ~= hmac or tonumber(timestamp) < os.time() then
-- if invalid, send to /auth/ again.
ngx.exec("/auth/")
end上面的**可以直接執行。我們用一些明文來簽名(這種情況下用的是乙個時間戳，當然你可以用任何你想用的),之後我們用密文生成hmac(雜湊資訊認證碼)，然後乙個簽名就生成了，這樣使用者就不能篡改為無效資訊了。
當使用者試圖載入乙個資源的時候，我們會檢查cookie裡面的簽名是否有效，如果是，就通過他的請求。反之，我們會把他們重定向到乙個發行口令的伺服器，這個伺服器會驗證並且在沒有的情況下給予他們乙個簽名的口令。
明銳的你可能會發現，上面的**存在時間上的漏洞。如果你沒有發現，別難過。嗯，也許會有點難過。
這裡是一段lua的**，用來比較兩個字串在恆定時間上的等值關係（因而能夠阻止任何時間上的攻擊，除非我忽視了什麼，這極為可能）：
複製** **如下:
function compare_strings(str1, str2)
-- constant-time string comparison function.
local same = true
for i = 1, #str1 do
-- if the two strings' l are different, sub()
-- will just return nil for the remaining length.
c1 = str1:sub(i,i)
c2 = str2:sub(i,i)
if c1 ~= c2 then
same = false
endend
return same
end我已經在函式上應用了時間來區分，如我所知，這是乙個在恆定時間下的等值字串。不同長度的字串會稍稍改變時間，也許是因為子過程sub應用了乙個不同的分支而導致的。而且，c1~=c2分支顯然不是恆定時間的，但是在實際中，它相當接近恆定，所以於我們的例子不會有影響。我更傾向於使用xor操作，從而確定兩個字串的xor結果是否為0, 不過lua似乎不包括二進位制位的xor操作。如果我在這個判斷上有誤，對於任何糾正我都很感激。
口令發行伺服器
現在，我們已經寫了一些很棒的口令檢查**，所有需要做的，只是寫乙個伺服器來真正的發行這些口令。我本可以用python以及flask來寫這個伺服器，不過我還是想用go做乙個嘗試，因為我是乙個計算機語言潮人而且go看上去「酷」。使用python大概會快一些，不過我樂意用go。
這個伺服器會彈出乙個http基礎驗證的表單，檢查你輸入的帳戶，如果正確，它會給你乙個簽名的口令，適合於乙個小時的**伺服器訪問。這樣，你只需要驗證外部服務一次，而隨後的身份驗證的檢查將在nginx層面，而且會相當的快。
請求處理器
寫乙個處理器，來彈出乙個基本的驗證窗體不是很難，但是go沒有完美的文件，所以我必須自己一點點尋獵。其實非常簡單，最終，這裡就是http基本驗證的go**：
複製** **如下:
設定口令和cookie
一旦我們驗證了乙個使用者之後，我們需要給他們的口令設定乙個cookie。我門只需要做我們用lua做過的同樣的事情，如上，只是更加簡單，因為go在標準庫裡面就包括乙個真加密包。這個**一樣很直接明了，即使沒有完全文件化：
複製** **如下:
}嘗試把他們放在一起
來完成我們這一大段美妙的組合，我們只需要乙個函式，用來檢查由使用者提供的驗證資訊，而且我們做到了！這裡是我從一些庫裡面汲取出來的**，當前它只是檢查乙個特定的使用者名稱／密碼的組合，所以和第三方的服務的整合就做為留給讀者的作業吧：
複製** **如下:
}結論我到目前對於nginx的lua模組還是有著相當的喜歡。它允許你在web伺服器的請求／響應週期裡面做一些簡單的操作，而且對於某些操作，比如為**伺服器做驗證的檢查，是很有意義的。這些事情對於乙個不可程式設計的web伺服器，一直很難，因此我們極可能需要寫自己的http**服務。
上面的**相當的簡短，而且優雅，所以我對於上面的所有都感到高興。我不能確定，這對於響應新增了多少額外的時間，不過，做乙個驗證是有好處的，我想這將值得去做（而且應該足夠快，所以不是乙個問題）。
另乙個好處就是，你可以僅使用乙個在nginxlocationblock裡面的單獨的directive來開啟它，所以沒有需要跟蹤的配置項。我發現，總體而言，這是乙個非常優雅的解決方案，而且我很高興的了解到nginx可以讓我去做這樣的事情，可能是將來我需要去做的。
本文標題: 使用lua編寫nginx伺服器的認證模組的方法
本文位址:
svrver伺服器編寫
include include include include include see notes include include include int main printf create listenfd d success n listenfd int opt 1 setsockopt li...
使用nginx搭建https伺服器
最近在研究nginx，整好遇到乙個需求就是希望伺服器與客戶端之間傳輸內容是加密的，防止中間監聽洩露資訊，但是去證書服務商那邊申請證書又不合算，因為訪問伺服器的都是內部人士，所以自己給自己頒發證書，忽略掉瀏覽器的不信任警報即可。下面是頒發證書和配置過程。首先確保機器上安裝了openssl和openss...
使用nginx搭建https伺服器
最近在研究nginx，整好遇到乙個需求就是希望伺服器與客戶端之間傳輸內容是加密的，防止中間監聽洩露資訊，但是去證書服務商那邊申請證書又不合算，因為訪問伺服器的都是內部人士，所以自己給自己頒發證書，忽略掉瀏覽器的不信任警報即可。下面是頒發證書和配置過程。首先確保機器上安裝了openssl和openss...