過去兩天里，我解決了一個非常有趣的問題。我用一個nginx服務器作為代理，需要能夠向其中添加一個認證層，使其能夠使用外部的認證源（比如某個web應用）來進行驗證，如果用戶在外部認證源有賬號，就可以在代理里認證通過。
需求一覽
我考慮了幾種解決方案，羅列如下：
- 用一個簡單的Python/Flask模塊來做代理和驗證。
- 一個使用subrequests做驗證的nginx模塊（nginx目前可以做到這一點）
- 使用Lua編寫一個nginxren認證模塊
很顯然，給整個系統添加額外請求將執行的不是很好，因為這將會增加延遲(特別是給每一個頁面文件都增加一個請求是很讓人煩惱的).這就意味著我們把subrequest模塊排除在外了。Python/Flash解決方案好像對nginx支持的也并不好，所以咱也把它排除了。就剩Lua了，當然nginx對原生化支持得不錯的。
因為我不想再擴展的服務器上對每一個請求都做認證，所以我決定生成一些令牌，這樣人們就可以將它保存起來，并把它呈現給服務器，然后服務器就讓請求通過。然而，因為Lua模塊沒有一種保持狀態的方式(我已經發現)，所以我們不能將令牌隨處存儲。當你沒有更多的內存時，怎樣來驗證用戶所說的話呢？
解決問題
加密簽名的方式可是咱的救星！我們可以拿用戶的用戶名和過期時間數據來給用戶添加簽名的cookies，這樣就能很容易的驗證每個用戶是誰了，同時我們就不用令牌了。
在nginx中，我們要做的就是直接在指定位置配置access_by_lua_file /our/file.lua，這樣這個指定位置就可以保護我們的腳本了。現在，讓我們一起來寫代碼：
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的代碼，用來比較兩個字符串在恒定時間上的等值關系（因而能夠阻止任何時間上的攻擊，除非我忽視了什么，這極為可能）：
-- Constant-time string comparison function.
local same = true
for i = 1, #str1 do
-- If the two strings' lengths 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
end
end
return same
end
我已經在函數上應用了時間來區分，如我所知，這是一個在恒定時間下的等值字符串。不同長度的字符串會稍稍改變時間，也許是因為子過程sub應用了一個不同的分支而導致的。而且，c1~=c2分支顯然不是恒定時間的，但是在實際中，它相當接近恒定，所以于我們的例子不會有影響。我更傾向于使用XOR操作，從而確定兩個字符串的XOR結果是否為0, 不過Lua似乎不包括二進制位的XOR操作。如果我在這個判斷上有誤，對于任何糾正我都很感激。
口令發行服務器
現在，我們已經寫了一些很棒的口令檢查代碼，所有需要做的，只是寫一個服務器來真正的發行這些口令。我本可以用Python以及Flask來寫這個服務器，不過我還是想用Go做一個嘗試，因為我是一個計算機語言潮人而且Go看上去“酷”。使用Python大概會快一些，不過我樂意用Go。
這個服務器會彈出一個HTTP基礎驗證的表單，檢查你輸入的帳戶，如果正確，它會給你一個簽名的口令，適合于一個小時的代理服務器訪問。這樣，你只需要驗證外部服務一次，而隨后的身份驗證的檢查將在nginx層面，而且會相當的快。
請求處理器
寫一個處理器，來彈出一個基本的驗證窗體不是很難，但是Go沒有完美的文檔，所以我必須自己一點點尋獵。其實非常簡單，最終，這里就是HTTP基本驗證的Go代碼：
if username := checkAuth(r); username == "" {
w.Header().Set("WWW-Authenticate", `Basic realm="The kingdom of Stavros"`)
w.WriteHeader(401)
w.Write([]byte("401 Unauthorized\n"))
} else {
fmt.Printf("Authenticated user %v.\n", username)
token := getToken()
setTokenCookie(w, token)
fmt.Fprintf(w, "<html><head><script>location.reload()</script></head></html>")
}
}
設置口令和cookie
一旦我們驗證了一個用戶之后，我們需要給他們的口令設置一個cookie。我門只需要做我們用Lua做過的同樣的事情，如上，只是更加簡單，因為Go在標準庫里面就包括一個真加密包。這個代碼一樣很直接明了，即使沒有完全文檔化：
expiration := int(time.Now().Unix()) + 3600
mac := hmac.New(sha1.New, []byte("some very secret string"))
mac.Write([]byte(fmt.Sprintf("%v", expiration)))
expectedMAC := fmt.Sprintf("%x", mac.Sum(nil))
return fmt.Sprintf("%v:%s", expiration, expectedMAC)
}
func setTokenCookie(w http.ResponseWriter, token string) {
rawCookie := fmt.Sprintf("MyToken=%s", token)
expire := time.Now().Add(time.Hour)
cookie := http.Cookie{"MyToken",
token,
"/",
".example.com",
expire,
expire.Format(time.UnixDate),
3600,
false,
true,
rawCookie,
[]string{rawCookie}}
http.SetCookie(w, &cookie)
}
嘗試把他們放在一起
來完成我們這一大段美妙的組合，我們只需要一個函數，用來檢查由用戶提供的驗證信息，而且我們做到了！這里是我從一些庫里面汲取出來的代碼，當前它只是檢查一個特定的用戶名／密碼的組合，所以和第三方的服務的集成就做為留給讀者的作業吧：
s := strings.SplitN(r.Header.Get("Authorization"), " ", 2)
if len(s) != 2 || s[0] != "Basic" {
return ""
}
b, err := base64.StdEncoding.DecodeString(s[1])
if err != nil {
return ""
}
pair := strings.SplitN(string(b), ":", 2)
if len(pair) != 2 {
return ""
}
if pair[0] != "username" || pair[1] != "password" {
return ""
}
return pair[0]
}
結論
我到目前對于nginx的Lua模塊還是有著相當的喜歡。它允許你在web服務器的請求／響應周期里面做一些簡單的操作，而且對于某些操作，比如為代理服務器做驗證的檢查，是很有意義的。這些事情對于一個不可編程的web服務器，一直很難，因此我們極可能需要寫自己的HTTP代理服務。
上面的代碼相當的簡短，而且優雅，所以我對于上面的所有都感到高興。我不能確定，這對于響應添加了多少額外的時間，不過，做一個驗證是有好處的，我想這將值得去做（而且應該足夠快，所以不是一個問題）。
另一個好處就是，你可以僅使用一個在nginxlocationblock里面的單獨的directive來開啟它，所以沒有需要跟蹤的配置項。我發現，總體而言，這是一個非常優雅的解決方案，而且我很高興的了解到nginx可以讓我去做這樣的事情，可能是將來我需要去做的。
