往MVC中加入了一个富文本编辑框,在提交信息的时候报了如下的错误:

从客户端(Content="<EM ><STRONG ><U >这是测试这...")中检测到有潜在危险的Request.Form 值。

说明: 请求验证过程检测到有潜在危险的客户端输入值,对请求的处理已经中止。该值可能指示存在危及应用程序安全的尝试,如跨站点脚本攻击。若要允许页面重写应用程序请求验证设置,请将 httpRuntime 配置节中的 requestValidationMode 特性设置为requestValidationMode="2.0"。示例: <httpRuntime requestValidationMode="2.0" / >。设置此值后,可通过在 Page 指令或 <pages > 配置节中设置 validateRequest="false" 禁用请求验证。但是,在这种情况下,强烈建议应用程序显式检查所有输入。有关更多信息,请参见http://go.microsoft.com/fwlink/?LinkId=153133。 
原以为就像普通的Asp.net页面一样,在头部的Page中加入ValidateRequest="false"就行了,谁知问题还是存在。弄了一个上午,问题终于解决,将解决方法汇总如下:
1,在出现该错误的页面头部的page中加入ValidateRequest="false",那么该页面的任何一次Post提交都不会再验证提交内容的安全性。 如:

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Manage/ViewMasterPageEdit.Master"     Inherits="System.Web.Mvc.ViewPage<MvcWebPhoto.Models.Entities.Article >"   ValidateRequest="false" % >

2,在web.config中的pages节中配置validateRequest="false",如:

<system.web > <pages validateRequest="false" ></pages >  </system.web >

但这样,整个项目中的所有Form请求都不再验证提交内容的安全性,极不提倡这种做法。
关于该问题的安全的解决方案可以参看本站: 从客户端中检测到有潜在危险的Request.Form值的详细解决方案
3,如果你使用的是.Net 3.5,MVC 2.0及更高的版本,那么可以在处理Post方法的Action添加一个特性:[ValidateInput(false)],这样处理就更加有针对性,提高页面的安全性。 如:

[HttpPost] [ValidateInput(false)] public ActionResult CatalogEdit(Catalog model) { return View(); }

重要: 如果你使用的是MVC 3.0,那么你会发现做了以上的设置后还是无效。这是因为你还需要在web.config中做以下设置:

<system.web > <httpRuntime requestValidationMode="2.0" / > </system.web >

(唉~ 非常非常的麻烦啊)

注意:在MVC项目中,Views文件夹下与主项目下,都会有一个web.config文件。Views下的web.config文件只对Views文件夹下面的文件有效。如果你要处理的页面不在Views下面,那么<httpRuntime requestValidationMode="2.0" / >一定要设置在主项目下的web.config中才有用。

mvc 从客户端 中检测到有潜在危险的 Request 值的更多相关文章

  1. ASP.NET MVC从客户端中检测到有潜在危险的 Request.Form 值

    ASP.NET MVC4(Razor)从客户端中检测到有潜在危险的 Request.Form 值 “/”应用程序中的服务器错误. 从客户端(Content=" sdfdddd ...&quo ...

  2. mvc 从客户端 中检测到有潜在危险的 Request.Form 值

    天往MVC中加入了一个富文本编辑框,在提交信息的时候报了如下的错误:从客户端(Content="<EM ><STRONG ><U >这是测试这...&qu ...

  3. MVC从客户端中检测到有潜在危险的Request.Form值的解决方法

    1.ASPX页面 在页面头部的page中加入ValidateRequest="false" 2.web.config中配置validateRequest="false&q ...

  4. 从客户端中检测到有潜在危险的 request.form值 以及 request.querystring[解决方法]

    一.从客户端中检测到有潜在危险的request.form值 当页面编辑或运行提交时,出现“从客户端中检测到有潜在危险的request.form值”问题,该怎么办呢?如下图所示: 下面博主汇总出现这种错 ...

  5. MVC中提示错误:从客户端中检测到有潜在危险的 Request.Form 值的详细解决方法

    今天往MVC中加入了一个富文本编辑框,在提交信息的时候报了如下的错误:从客户端(Content="<EM ><STRONG ><U >这是测试这...&q ...

  6. 【异常记录(七)】MVC:从客户端中检测到有潜在危险的 Request.Form 值 的解决方法 [转]

    从客户端(Content="<EM ><STRONG ><U >这是测试这...")中检测到有潜在危险的Request.Form 值. 说明:  ...

  7. asp.net MVC 自定义模型绑定 从客户端中检测到有潜在危险的 Request.QueryString 值

    asp.net mvc 自定义模型绑定 有潜在的Requset.Form 自定义了一个模型绑定器.前端会传过来一些敏感字符.调用bindContext. valueProvider.GetValue( ...

  8. 从客户端(&)中检测到有潜在危险的 Request.Path 值

    首先,这个问题出现在 ASP.NET MVC 应用程序中,所以下面的解决方式都是在这个环境下. 关于这个问题,网上又很多的答案,当时也搜了一些: A potentially dangerous Req ...

  9. 从客户端中检测到有潜在危险的Request.Form 值

    今天往MVC中加入了一个富文本编辑框,在提交信息的时候报了如下的错误:从客户端(Content="<EM ><STRONG ><U >这是测试这...&q ...

随机推荐

  1. 自动化测试之旅--selenium+python--001

    在学习selenium之前,首先感谢网络上的虫师和乙醇老师,或许他们并不知道我这个菜鸟的存在,但是我仍然要感谢他们,因为在学习的路上拜读了许多他们的博客和文章,对于我来说有着很重要的意义,因此在学习之 ...

  2. sencha touch textarea 手机上不显示滚动条,且不能滚动

    最近在项目中发现 sencha touch 中的 textarea 在手机上不显示滚动条,也不能滚动. 在浏览器中之所以能显示滚动条滚动,那是浏览器为 textarea 添加的滚动条. 但在手机中是不 ...

  3. Git学习系列之Git产生的背景

    不多说,直接上干货! 史上最浅显易懂的Git教程! 为什么要编写这个教程?因为我在学习Git的过程中,买过书,也在网上Google了一堆Git相关的文章和教程,但令人失望的是,这些教程不是难得令人发指 ...

  4. java ee的map

  5. Linux学习(1)

    Linux操作系统核心"Kernel",位于操作系统底层,是连接Shell.KDE.应用和硬件的接口,核心必须支持的管理事物: 1)系统调用接口(System Call Inter ...

  6. Expression Blend实例中文教程(6) - 项目控件和用户交互控件快速入门

    前文我们曾经描述过,微软把Silverlight控件大致分为三类: 第一类: Layout Controls(布局控件) 第二类: Item Controls (项目控件) 第三类: User Int ...

  7. CSS学习(二)

    display :   block    inline-block    inline block此元素将显示为块级元素,此元素前后会带有换行符. inline默认.此元素会被显示为内联元素,元素前后 ...

  8. Nginx配置整理

    不论是本地开发,还是远程到 Server 开发,还是给提供 demo 给人看效果,我们时常需要对 Nginx 做配置,Nginx 的配置项相当多,如果考虑性能配置起来会比较麻烦.不过,我们往往只是需要 ...

  9. request方法总结

     1.获得指定的头 String header = response.getHeader("user-agent"); 2.获得所有头的名称 Enumeration<Stri ...

  10. UrlRewrite 的配置和使用总结

    UrlRewrite就是我们通常说的地址重写,用户得到的全部都是经过处理后的URL地址.     主要优点 一:提高安全性,可以有效的避免一些参数名.ID等完全暴露在用户面前,如果用户随便乱输的话,不 ...