有鵬友在如鵬網的QQ群中提了一個問題：

請問，在ASP.Net中如何隱藏一個MenuItem，我想根據不同的許可權，對功能選單進行隱藏，用style不行。

如果要僅僅解答這個問題，很好解答，答案很簡單：

給MenuItem設定Value，然後用從根節點開始的MenuItem父子關係構成的ValuePath路徑FindItem，然後把它從父節點中Remove掉即可。如下

<asp:MenuID="Menu1"runat="server">

<Items>

<asp:MenuItemText="系統管理"Value="SysMgr">

<

<asp:MenuItemText="配置管理"Value="ConfigMgr"></asp:MenuItem>

</asp:MenuItem>

<asp:MenuItemText="新建項"Value="新建項"></asp:MenuItem>

</Items>

</asp:Menu>

MenuItem mi = Menu1.FindItem("SysMgr/ConfigMgr"

if (mi != null)

            {

                mi.Parent.ChildItems.Remove(mi);

            }

如果只是簡單的分享一下這個問題的話，我就沒必要寫一篇部落格了，我想接下來分享三個問題：

1）為什麼這種“隱藏選單”的方案非常不安全；

2）為什麼說ASP.net WebForm是個坑；

3）為什麼ASP.Net MVC應用越來越廣；

為什麼“隱藏選單”就是掩耳盜鈴

不少網站系統開發的時候是這樣做許可權控制的：如果當前使用者沒有這個選單的執行許可權，就把選單隱藏起來，認為這樣就“安全”了。但是Http協議是開放的，訪問者可以採用直接在位址列輸入“沒有許可權訪問”的頁面的地址或者製造一個模擬執行被隱藏選單的Http請求，這樣就可以輕鬆的訪問“沒有許可權訪問”的頁面了。

類似的安全漏洞還有：

1）把使用者不可以看的資料在列表中隱藏掉，豈不知使用者可以直接拼湊url訪問其他資料或者刪除它不能刪除的資料；

2）做手機號驗證的時候把被驗證的手機號寫到隱藏欄位中，豈不知這樣使用者就可以先用一個真實的手機號請求驗證碼，在驗證環節再修改隱藏欄位中的手機號為一個假手機號，這樣一個假手機號進行認證了

3）普通訪問者通過http://www.rupeng.com/UserInfo/36這樣的url可以看到自己的個人資訊，如果不做控制的話，惡意訪問者就可以用http://www.rupeng.com/UserInfo/1、http://www.rupeng.com/UserInfo/2、http://www.rupeng.com/UserInfo/3……這樣的方式一個個的把你的註冊使用者的資訊全部“拖庫”下來。

如此等等……

正確的做法是：

1）沒有許可權看的資料不僅要隱藏，還要在“看資料”的頁面中進行“二次查崗”，再次檢查當前使用者是否有檢視許可權；

2）把這些客戶端篡改後就會對安全性有威脅的資料放到伺服器端Session中；

不僅B/S系統有這樣的安全漏洞，很多C/S系統這樣的漏洞更多，我看到過很多C/S系統是客戶端直連資料庫，稍微懂一點程式設計的人可以直接訪問資料庫“為所欲為”。正確的做法應該是使用WCF等技術開發一箇中間層，把業務邏輯、許可權控制等寫到中間層，資料庫訪問等操作都在中間層完成，對外暴露介面，客戶端程式去訪問中間層介面，並不直接訪問資料庫。

對於有一定經驗的開發者來講，這點大家應該都清楚，我在這裡就不再多說，如果有鵬友不清楚這一點的，可以在評論中繼續交流。

為什麼說ASP.net WebForm是個坑

對我有一些瞭解的朋友會知道，這幾年我一直在.Net技術圈倡導一個理念“不做只會拖ASP.Net WebForm控制元件的菜鳥”，不知道和我這點努力是不是有關係，目前國內重度使用ASP.Net WebForm的公司越來越少，更多的公司開始輕量級的使用ASP.net WebForm或者直接乾脆轉向使用ASP.net MVC。

當然並不是說“ASP.net WebForm不好”，因為照樣有很多不錯的系統是使用ASP.net WebForm開發出來的，我這裡想說的是“ASP.net WebForm容易被誤用”，說的嚴重點“ASP.Net很容易誘導犯罪”。

就像如果你選擇了一個大美女跟你共處一室，你做了順從內心但是違反了法律的事情，這不是大美女的責任，你不能譴責“誰讓她穿的那麼暴露，都是她的責任”，是你的錯就要你來承擔。如果你當初選擇跟鳳姐共處一室，我相信你更多的是跟她討論《故事會》、《知音》等古典文學話題。

同理，有人能把ASP.Net WebForm用的“坐懷不亂”，但更多的人用ASP.Net WebForm的時候容易“日後再說” 。那麼ASP.Net WebForm有哪些誘導大家犯罪的地方呢？

ASP.net WebForm設計的初衷就是微軟想複製VB、WinForm等技術的成功路線。

如果直接使用Win32 API進行Windows程式開發，你需要面對訊息迴圈、訊息機制、結構體、控制代碼等等各種複雜的問題，而使用VB、WinForm等技術，只要明白“控制元件、屬性、方法、事件”這幾個概念，就可以拖拖拽拽的開發一個系統出來。

同樣的，進行Web開發的時候程式設計師也需要理解Http協議、Cookie等細節的複雜東西，微軟想用WebForm這樣一種類似WinForm的拖控制元件的傻瓜化開發方式把程式設計師再次解放出來。但是事與願違，Web系統的安全性、效率等的要求決定了“把開發人員變傻瓜化”這樣一條路是走不通的，Web程式設計師必須明確的知道生成的每一個html字元的意義、瀏覽器和伺服器之間的通訊細節，才能開發出安全、高效的Web系統出來。

而ASP.net WebForm把底層東西都封裝好了，html的生成、請求的處理都是在內部神奇的偷偷完成的。對於不求甚解的初學者，秉承著“能實現就行”的心態，用ASP.net WebForm的這些神奇的控制元件開發出了速度緩慢、漏洞百出的系統。而且由於不知道ASP.net WebForm是怎麼生成那樣一坨坨的html程式碼以及怎麼樣處理我們的請求的，所以一旦遇到問題，就只能去社群中“求大牛賜予我一個神奇的控制元件”、“求大牛賜予我一段神奇的程式碼可以神奇的解決我神奇的問題”。對於想精確的控制生成的Html、精確的控制請求處理過程的程式設計師來講，ASP.net WebForm就又有點自作聰明的幫我們做很多事情，束手束腳，有時候這些控制元件太智慧，也會讓高手一不留神犯錯。

如果是開發一個簡單的、安全性要求不高的Web系統，ASP.net WebForm也能快速開發出來滿足要求了，但是如果要想開發複雜的、訪問量比較大的、對安全性很重視的Web系統，一定要謹慎，儘量不重度用ASP.net WebForm，要麼只是把aspx當成模板引擎用，要麼就像如鵬網一樣使用ASP.net MVC來進行開發。

為什麼ASP.Net MVC應用越來越廣

上面我提到了Web開發者必須有能力對“請求、處理、響應”的整個過程進行控制，必須明白生成的Html是什麼回事、必須明白每個請求是怎麼發出去的，很顯然ASP.Net WebForm這條路走錯了。而Struts、ROR等這些輕量級的框架則發展越來越好（當然也不知道Sun公司哪根筋抽了，竟然在本來已經很好的Java世界中搞了一個模仿WebForm的JSF框架出來，還把它搞成了Java標準，無奈乎沒人Diao這個標準庫。這就是傳說的“倒行逆施”吧。）

因此開源世界開始製造ASP.net的第三方MVC框架，比如移植自Struts的NStruts；我在如鵬網線上程式設計訓練營的.Net培訓課程中也用“HttpHandler+Razor模板引擎”搭建了一個MVC框架；剛剛還模仿Java中的“Servlet+RequestDispatcher+JSP”MVC做法搞了一個只用asp.net webform、完全不用第三方庫的“HttpHandler+Server.Transfer+aspx”MVC框架，很有意思，稍後我會在我的微信朋友圈寫文章分享一下這個大家一眼就可以看懂、同時又“很MVC”的框架。我的微訊號是：yzk369

不過微軟社群的特點是“大家都不信任第三方框架，只有微軟官方出的大家才用”，所以NStruts之類的都沒有得到廣泛應用。還好微軟公司及早認識到了這一點，研發出了集Struts、ROR等優點於一身的ASP.Net MVC。業務程式碼和UI分離，程式設計師可以在View模板對生成的Html進行精細化的控制，Controller只管對客戶端的請求進行處理，整個開發過程清晰明瞭。沒有了討厭的IsPostBack、沒有了DataBind、沒有了精神病似得OnDeleted和OnDeleting、沒有了然並卵的“頁面生命週期”……

請求→處理→響應，就是這麼簡潔！

乾淨利落，漂亮的不像實力派！

不過，由於各種原因，目前還是有一些專案、一些開發人員在使用ASP.net MVC，我準備近期搞一次ASP.net MVC的免費網路公開課，給大家講一講。為了公開課能更好的滿足大家的需求，我設計了一個調查問卷，收集一下大家的想法。公開課時間確定之後也會通知大家。

如鵬網.Net培訓班正在報名，有網路的地方就可以參加如鵬網的學習，學完就能高薪就業，點選此處瞭解

三年前只要懂“三層架構”就可以說“精通分層架構”；現在則需要懂IOC（AutoFac等）、CodeFirst、lambda、DTO等才值錢；

三年前只要會SQLServer就可以說自己“精通資料庫開發”；現在則需還需要掌握MySQL等開源資料庫才能說是“.Net開源”時代的程式設計師；

三年前只要會進行使用者上傳內容的安全性處理即可；現在則需要熟悉雲端儲存、CDN等才能在雲端計算時代遊刃有餘；

三年前只要掌握Lucene.Net就會說自己“熟悉站內搜尋引擎開發”；現在大家都用ElasticSearch了，你還用Lucene.Net就太老土了；

三年前發郵件還是用SmtpClient；現在做大型網站發郵件必須用雲郵件引擎；

三年前快取就是Context.Cache；現在則是Redis、Memcached的天下；

如鵬網再次引領.Net社群技術潮流！點選此處瞭解如鵬網.Net最新課程