這樣的需求可能就沒有辦法在**的應用程式裡面實現了，因為在請求1.jpg這個檔案的時候，並沒有涉及到**應用的
任何邏輯，而是在web伺服器承載程式（iis，apache）接到請求報文之後，如果對應的請求檔案在web伺服器承載程式擁有讀許可權的話，那麼則返回這個檔案，否則列印的是web伺服器承載程式的拒絕請求資訊，通常被請求的檔案在web伺服器承載程式的許可權應當是繼承作業系統。
但事實上我參考了網路上面，關於的防盜煉系統的一些實現方案，大都是通過判斷http請求報文中的urlreference資訊是否為本站來實現。參考：
這篇文章給出了一種解決方案，按照他的方法，如果自己實現.net framework提供的
ihttphandler介面的話，可以手動的對http請求進行處理。通過對http請求資訊的判斷，然後作出相應的邏輯。
這種方案對於一般的防盜煉應用也就夠了，但是對於訪問許可權控制系統，不得不考慮到有惡意的情況。比如客戶端是非標準瀏覽器， 例如自己寫的乙個http請求程式，其目的是自己構造http請求報文，那麼這樣的程式完全可以偽裝urlreference和host為同一主機。假設uri為
http://www.***.com/file1的檔案，它授權使用者a具有讀許可權，那麼我們就不能通過判斷請求報文的urlreference來確認是否能夠將file1檔案暴露出去。因為使用者b可能不具有訪問file1檔案的許可權，但是可能具有訪問引用了file1檔案的file2檔案的許可權，而file2通
常是.aspx檔案。
和同學討論了一下，如果採用基於角色的訪問控制思想，可以
彌補防盜煉方法的不足。大概思路
就是做乙個伺服器承載程式的外掛程式，然後所有的http請求都通過那個外掛程式來處理，登陸後，資訊寫到session中，獲取請求的檔案id，再查詢表判斷該使用者是否具有訪問該檔案的許可權，如果有則返回檔案，否則返回錯誤資訊。如果基於cookie的session是安全的話，這種方法可以很好的彌補防盜煉方法的不足。
稍微總結一下，假設要實現這樣的乙個功能：對於web 伺服器上的特定資源，並須經過授權訪問，那麼我們可以擷取對於該主機所有的http請求，並獲取請求的檔案，再通過查詢角色許可權或者檔案許可權資料庫，如果授權通過則返回檔案，否則返回拒絕請求資訊。
以上是關於web系統訪問控制的一些思考，還沒有動手檢驗其正確性。不過即使如果要實現這樣的乙個需求，也可以順著這種思路的方向做下去。
也談談關於WEB的感想
距離上次在發表博文已經是數年以前了，想想自己也確實有夠懶惰的，實為不該。引起我想發這篇博文的原因是 charlie.zheng 所發表的 web系統開發構架再思考 前後端的完全分離 廢話不多說，下面就來敘說一下自己的想法。我覺得程式設計師應該像大廚，各種解決問題的方法就像大廚手中的食材與調料。在一道...
Linux關於訪問許可權的設定
一 linux檔案和目錄許可權管理 1 許可權說明 1 r 表示具有讀取檔案內容的許可權 r 4 2 w 表示具有新增，修改檔案內容的許可權 w 2 3 x 表示具有執行檔案的許可權，同時需要有r許可權 x 1 4 預設建立目錄 許可權 755 5 預設建立檔案 許可權 644 6 9個字元，表示許...
使用自己的網域名稱訪問本地WEB應用
本地安裝了web服務端，怎樣通過自定義網域名稱方式實現從公網訪問本地web應用？本文將介紹具體的實現步驟。預設安裝的web埠是80。在網域名稱服務商註冊並購買的網域名稱必須要完成網域名稱備案，否則無法使用網域名稱訪問 具體備案細節可以參考網域名稱服務商提供的備案流程指導文件。例如自己申請並完成備案的...