在一些**中，我們雖然使用了ajax，但是我們並不希望使用者能夠私自呼叫這些ajax，因為有些ajax呼叫會包含對資料的更新操作，即使是唯讀的操作，也不希望使用者能在本地進行直接呼叫。
在 michael chen 的這篇文章中 [url] ，提及了ajax應用中的安全問題，並且給出了乙個臨時的解決方案。雖然我用的不是 buffalo ，而是 dwr，但是這篇文章對於 dwr 仍然有幫助。
不過正如 michael chen 在文章中所說，他給出的解決方案沒有經過詳細的測試，所以我在用了一段時間之後，還真就發現了問題。
文中的解決方案的關鍵是判斷 request的cookie，雖然 dwr 中取得request的方式與 buffalo不同，但是並不影響，而且經過測試，也確實有效。
可是之後**增加了靜態頁面的生成功能，這樣使用者就可以直接訪問靜態頁，而非提交乙個請求。結果問題出現了。
當在靜態頁中呼叫 dwr 的應用時，request的 cookie 也是空的。這樣之前的解決方案就無效了。
那麼怎麼辦？或許 http 的 header 中的 referer 能給點幫助！
string referer = request.getheader("referer");
通過這樣的方式我們就能得到乙個 referer，那麼這個 referer是什麼呢？就是請求這個ajax的位址。我想熟悉盜鏈功能的朋友對它不會陌生。
這樣，當我們從 www.***.com 請求 www.***.com/index.html 時，而這個 index.html 中又包含乙個 ajax 的呼叫的時候，我們就可以這麼判斷：
string referer = request.getheader("referer");
if(!referer.startswith(""))
這樣就可以保證只允許**內部的資源訪問 ajax 的應用了。
經過測試，可以做到避免使用瀏覽器的方式從本地私自訪問ajax應用。但是我想這種方式仍然會存在漏洞，希望大家能給出更好的方案。
關於密碼的安全性問題
之前看到網上有很多知名企業 都爆出密碼洩露的問題，然後我們現在做一些關於註冊和登入還有其他方方面面涉及資料庫資料的內容。如果我們一般做註冊頁面，將使用者註冊的密碼存進資料庫，一般建議不要單純的將密碼存進去，因為這樣安全性絕對是最低的，如果不想讓別人簡簡單單就拿到我們密碼的話，那就得在密碼上面做點小功...
關於密碼的安全性問題
最近看到網上有很多知名企業 都爆出密碼洩露的問題，然後我們現在做一些關於註冊和登入還有其他方方面面涉及資料庫資料的內容。如果我們一般做註冊頁面，將使用者註冊的密碼存進資料庫，一般建議不要單純的將密碼存進去，因為這樣安全性絕對是最低的，如果不想讓別人簡簡單單就拿到我們密碼的話，那就得在密碼上面做點小功...
安全性問題
更改預設密碼 大量關鍵資訊 金融的 市場的 私人的 難以置信地在 inter 上失竊，不僅因為不夠嚴密的安全體系結構，還因為不負責任地留下了資料庫和系統的預設安裝密碼。如果您不希望成為上述的一員，一定要更改 rdbms windows nt 計算機和其他資源中眾所周知的使用者預設登入密碼。檢查入口處...