当ASP.NET发生Viewstate MAC的验证失败(machineKey)

问题是这样的,当 ASP.NET 因为网页还没全部下载完成时,使用者就按下网页中的任意一个PostBack 的按钮或链接时,就会发生「Viewstate MAC 的验证失败」的错误讯息! 这问题实在很难除错(DEBUG),我想很多人连发生的原因都不知道,主要的发生原因有两种: 1. 当网站采用 Web-farm 架构时,也就是一个网站采用负载平衡的架构,用多台 Web 主机同时提供服务时。 因为 ASP.NET 预设会将 Viewstate 编码加密,验证数据的加密类型是 SHA1,验证加密数据的密钥(Key)预设是「自动产生」,所以每一台Web主机所产生的Key都不一样,所以你采用多台主机同时提供服务时,就可能会遇到从第一台Web主机读到的内容,做 PostBack 时可能会 PostBack 到第二台主机,但第二台主机看不懂第一台主机编码过的 Viewstate,而导致「Viewstate MAC 的验证失败」的例外发生! 这时你需要统一每一台主机的 machineKey 才能让每一台的编码加密的内容可以被正确验证!建议您去 The Code Project 网站看这份文件:ASP.NET machineKey Generator 上面有完整说明! 2. 因为网页还没全部下载完成,导致页面的状态不完整时就对服务器发出 PostBack 要求,因为 ViewState 不完整,而导致 Viewstate 验证失败。 这个问题只能将修改网站的 web.config 设定将 Viewstate 全部关闭才不会发生错误!如下: <pages enableEventValidation=”false” viewStateEncryptionMode =”Never” enableViewStateMac=”false”/>

对List取交集、联集及差集

前言 最近在项目中,刚好遇到这个需求,需要比对两个List,进行一些交集等操作,在以前我们可能需要写很多行来完成这些动作,但现在我们只需要藉由LinQ就能轻松达到我们的目的啰! 实际演练 ※本文使用int为例,若为使用自定义之DataModel,需实现IEquatable接口才能使用 1. 取交集 (A和B都有) List A : { 1 , 2 , 3 , 5 , 9 } List B : { 4 , 3 , 9 } var intersectedList = list1.Intersect(list2); 结果 : { 3 , 9 } 判断A和B是否有交集 bool isIntersected = list1.Intersect(list2).Count() > 0 2. 取差集 (A有,B没有) List A :… Continue reading 对List取交集、联集及差集

RBAC基于角色的访问控制

基于角色的访问控制(Role-Based Access Control)作为传统访问控制(自主访问,强制访问)的有前景的代替受到广泛的关注。在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。 RBAC支持三个著名的安全原则:最小权限原则,责任分离原则和数据抽象原则。最小权限原则之所以被RBAC所支持,是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现,比如要求一个计帐员和财务管理员共参与同一过帐。数据抽象可以通过权限的抽象来体现,如财务操作用借款、存款等抽象权限,而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。 RBAC有许多部件,这使得RBAC的管理多面化。尤其是,我们要分割这些问题来讨论:用户与角色的指派;角色与权限的指派;为定义角色的继承进行的角色与角色的指派。这些活动都要求把用户和权限联系起来。然而在很多情况下它们最好由不同的管理员或管理角色来做。对角色指派权限是典型的应用管理者的职责。银行应用中,把借款、存款操作权限指派给出纳角色,把批准贷款操作权限指派给经理角色。而将具体人员指派给相应的出纳角色和管理者角色是人事管理的范畴。角色与角色的指派包含用户与角色的指派、角色与权限的指派的一些特点。更一般来说,角色与角色的关系体现了更广泛的策略。 RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。

MVVM模式

MVVM概述 MVVM是Model-View-ViewModel的简写。 微软的WPF带来了新的技术体验,如Sliverlight、音频、视频、3D、动画……,这导致了软件UI层更加细节化、可定制化。同时,在技术层面,WPF也带来了 诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性揉合进去,以应对客户日益复杂的需求变化。 MVVM 功能图 实例解析 WPF的数据绑定与Presentation Model相结合是非常好的做法,使得开发人员可以将View和逻辑分离出来,但这种数据绑定技术非常简单实用,也是WPF所特有的,所以我们又称之为Model-View-ViewModel(MVVM)。这种模式跟经典的MVP(Model-View-Presenter)模式很相似,除了你需要一个为View量身定制的model,这个model就是ViewModel。ViewModel包含所有由UI特定的接口和属性,并由一个 ViewModel 的视图的绑定属性,并可获得二者之间的松散耦合,所以需要在ViewModel 直接更新视图中编写相应代码。数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证。 在视图(View)部分,通常也就是一个Aspx页面。在以前设计模式中由于没有清晰的职责划分,UI 层经常成为逻辑层的全能代理,而后者实际上属于应用程序的其他层。MVP 里的M 其实和MVC里的M是一个,都是封装了核心数据、逻辑和功能的计算关系的模型,而V是视图(窗体),P就是封装了窗体中的所有操作、响应用户的输入输出、事件等,与MVC里的C差不多,区别是MVC是系统级架构的,而MVP是用在某个特定页面上的,也就是说MVP的灵活性要远远大于MVC,实现起来也极为简单。 我们再从IView这个interface层来解析,它可以帮助我们把各类UI与逻辑层解耦,同时可以从UI层进入自动化测试(Unit/Automatic Test)并提供了入口,在以前可以由WinForm/Web Form/MFC等编写的UI是通过事件Windows消息与IView层沟通的。WPF与IView层的沟通,最佳的手段是使用Binding,当然,也可以使用事件;Presenter层要实现IView,多态机制可以保证运行时UI层显示恰当的数据。比如Binding,在程序中,你可能看到Binding的Source是某个interface类型的变量,实际上,这个interface变量引用着的对象才是真正的数据源。 MVC模式大家都已经非常熟悉了,在这里我就不赘述,这些模式也是依次进化而形成MVC—>MVP—>MVVM。有一句话说的好:当物体受到接力的时候,凡是有界面的地方就是最容易被撕下来的地方。因此,IView作为公共视图接口约束(契约)的一层意思;View则能传达解耦的一层意思。 设计模式 因为WPF技术出现,从而使MVP设计模式有所改进,MVVM 模式便是使用的是数据绑定基础架构。它们可以轻松构建UI的必要元素。 可以参考The Composite Application Guidance for WPF(prism) View绑定到ViewModel,然后执行一些命令在向它请求一个动作。而反过来,ViewModel跟Model通讯,告诉它更新来响应UI。这样便使得为应用构建UI非常的容易。往一个应用程序上贴一个界面越容易,外观设计师就越容易使用Blend来创建一个漂亮的界面。同时,当UI和功能越来越松耦合的时候,功能的可测试性就越来越强。 在MVP模式中,为了让UI层能够从逻辑层上分离下来,设计师们在UI层与逻辑层之间加了一层interface。无论是UI开发人员还是数据开发人员,都要尊重这个契约、按照它进行设计和开发。这样,理想状态下无论是Web UI还是Window UI就都可以使用同一套数据逻辑了。借鉴MVP的IView层,养成习惯。View Model听起来比Presenter要贴切得多;会把一些跟事件、命令相关的东西放在MVC的’C’,或者是MVVM的’Vm’ MVVM优点 MVVM模式和MVC模式一样,主要目的是分离视图(View)和模型(Model),有几大有点: 低耦合。视图(View)可以独立于Model变化和修改,一个ViewModel可以绑定到不同的”View”上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。 可重用性。你可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。  独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计,使用Expression Blend可以很容易设计界面并生成xaml代码。 可测试。界面素来是比较难于测试的,而现在测试可以针对ViewModel来写。 MVVM控件 使用MVVM来开发用户控件[1]。由于用户控件在大部分情况下不涉及到数据的持久化,所以如果将M纯粹理解为DomainModel的话,使用MVVM模式来进行自定义控件开发实际上可以省略掉M,变成了VVM。