過去兩天里，我解決了一個非常有趣的問題。我用一個nginx服務(wù)器作為代理，需要能夠向其中添加一個認(rèn)證層，使其能夠使用外部的認(rèn)證源（比如某個web應(yīng)用）來進行驗證，如果用戶在外部認(rèn)證源有賬號，就可以在代理里認(rèn)證通過。
需求一覽
我考慮了幾種解決方案，羅列如下：
很顯然，給整個系統(tǒng)添加額外請求將執(zhí)行的不是很好，因為這將會增加延遲(特別是給每一個頁面文件都增加一個請求是很讓人煩惱的).這就意味著我們把subrequest模塊排除在外了。Python/Flash解決方案好像對nginx支持的也并不好，所以咱也把它排除了。就剩Lua了，當(dāng)然nginx對原生化支持得不錯的。
因為我不想再擴展的服務(wù)器上對每一個請求都做認(rèn)證，所以我決定生成一些令牌，這樣人們就可以將它保存起來，并把它呈現(xiàn)給服務(wù)器，然后服務(wù)器就讓請求通過。然而，因為Lua模塊沒有一種保持狀態(tài)的方式(我已經(jīng)發(fā)現(xiàn))，所以我們不能將令牌隨處存儲。當(dāng)你沒有更多的內(nèi)存時，怎樣來驗證用戶所說的話呢？
解決問題
加密簽名的方式可是咱的救星！我們可以拿用戶的用戶名和過期時間數(shù)據(jù)來給用戶添加簽名的cookies，這樣就能很容易的驗證每個用戶是誰了，同時我們就不用令牌了。
在nginx中，我們要做的就是直接在指定位置配置access_by_lua_file /our/file.lua，這樣這個指定位置就可以保護我們的腳本了?，F(xiàn)在，讓我們一起來寫代碼：
-- 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
上面的代碼可以直接運行。我們用一些明文來簽名(這種情況下用的是一個時間戳，當(dāng)然你可以用任何你想用的),之后我們用密文生成HMAC(哈希信息認(rèn)證碼)，然后一個簽名就生成了，這樣用戶就不能篡改為無效信息了。
當(dāng)用戶試圖載入一個資源的時候，我們會檢查cookie里面的簽名是否有效，如果是，就通過他的請求。反之，我們會把他們重定向到一個發(fā)行口令的服務(wù)器，這個服務(wù)器會驗證并且在沒有的情況下給予他們一個簽名的口令。
明銳的你可能會發(fā)現(xiàn)，上面的代碼存在時間上的漏洞。如果你沒有發(fā)現(xiàn)，別難過。嗯，也許會有點難過。
這里是一段Lua的代碼，用來比較兩個字符串在恒定時間上的等值關(guān)系（因而能夠阻止任何時間上的攻擊，除非我忽視了什么，這極為可能）：
我已經(jīng)在函數(shù)上應(yīng)用了時間來區(qū)分，如我所知，這是一個在恒定時間下的等值字符串。不同長度的字符串會稍稍改變時間，也許是因為子過程sub應(yīng)用了一個不同的分支而導(dǎo)致的。而且，c1~=c2分支顯然不是恒定時間的，但是在實際中，它相當(dāng)接近恒定，所以于我們的例子不會有影響。我更傾向于使用XOR操作，從而確定兩個字符串的XOR結(jié)果是否為0, 不過Lua似乎不包括二進制位的XOR操作。如果我在這個判斷上有誤，對于任何糾正我都很感激。
口令發(fā)行服務(wù)器
現(xiàn)在，我們已經(jīng)寫了一些很棒的口令檢查代碼，所有需要做的，只是寫一個服務(wù)器來真正的發(fā)行這些口令。我本可以用Python以及Flask來寫這個服務(wù)器，不過我還是想用Go做一個嘗試，因為我是一個計算機語言潮人而且Go看上去“酷”。使用Python大概會快一些，不過我樂意用Go。
這個服務(wù)器會彈出一個HTTP基礎(chǔ)驗證的表單，檢查你輸入的帳戶，如果正確，它會給你一個簽名的口令，適合于一個小時的代理服務(wù)器訪問。這樣，你只需要驗證外部服務(wù)一次，而隨后的身份驗證的檢查將在nginx層面，而且會相當(dāng)?shù)目臁?/p>
請求處理器
寫一個處理器，來彈出一個基本的驗證窗體不是很難，但是Go沒有完美的文檔，所以我必須自己一點點尋獵。其實非常簡單，最終，這里就是HTTP基本驗證的Go代碼：
設(shè)置口令和cookie
一旦我們驗證了一個用戶之后，我們需要給他們的口令設(shè)置一個cookie。我門只需要做我們用Lua做過的同樣的事情，如上，只是更加簡單，因為Go在標(biāo)準(zhǔn)庫里面就包括一個真加密包。這個代碼一樣很直接明了，即使沒有完全文檔化：
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)
}
嘗試把他們放在一起
來完成我們這一大段美妙的組合，我們只需要一個函數(shù)，用來檢查由用戶提供的驗證信息，而且我們做到了！這里是我從一些庫里面汲取出來的代碼，當(dāng)前它只是檢查一個特定的用戶名／密碼的組合，所以和第三方的服務(wù)的集成就做為留給讀者的作業(yè)吧：
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]
}
結(jié)論
我到目前對于nginx的Lua模塊還是有著相當(dāng)?shù)南矚g。它允許你在web服務(wù)器的請求／響應(yīng)周期里面做一些簡單的操作，而且對于某些操作，比如為代理服務(wù)器做驗證的檢查，是很有意義的。這些事情對于一個不可編程的web服務(wù)器，一直很難，因此我們極可能需要寫自己的HTTP代理服務(wù)。
上面的代碼相當(dāng)?shù)暮喍蹋覂?yōu)雅，所以我對于上面的所有都感到高興。我不能確定，這對于響應(yīng)添加了多少額外的時間，不過，做一個驗證是有好處的，我想這將值得去做（而且應(yīng)該足夠快，所以不是一個問題）。
另一個好處就是，你可以僅使用一個在nginxlocationblock里面的單獨的directive來開啟它，所以沒有需要跟蹤的配置項。我發(fā)現(xiàn)，總體而言，這是一個非常優(yōu)雅的解決方案，而且我很高興的了解到nginx可以讓我去做這樣的事情，可能是將來我需要去做的。
新聞熱點
疑難解答
圖片精選
