无效的回发或回调参数 [英] Invalid postback or callback argument

问题描述

我有一个ASP.net应用程序在开发环境中工作正常，但在生产环境中，当单击执行回发的链接时，将抛出以下异常。任何想法？

无效的回发或回调参数。
使用

在
页面中配置或<％@ Page
EnableEventValidation =true％>启用事件验证。为了安全起见，此
功能验证
回发或回调事件的参数是从
最初呈现的服务器控件发起的
。如果
的数据是有效和预期的，请使用
ClientScriptManager.RegisterForEventValidation
方法来注册
回传或
验证的回调数据。

编辑：似乎只有在使用IE6浏览时才会发生，但不是IE7，任何想法？

解决方案

问题描述：
这是很多ASP.NET初学者面对，发布和询问的常见问题。通常情况下，他们会发布以下错误消息，并寻求解决方案，而无需分享他们正在尝试的内容。

[ArgumentException：无效的回发或回调参数。使用配置或页面中的％@ Page EnableEventValidation =true％>启用事件验证。为了安全起见，此功能验证回发或回调事件的参数来自最初呈现给它们的服务器控件。如果数据是有效和预期的，请使用ClientScriptManager.RegisterForEventValidation方法，以注册回发或回调数据进行验证。]

尽管错误堆栈跟踪本身表示一个通过设置事件验证来快速解析，它不是一个推荐的解决方案，因为它打开一个安全漏洞。总是很好知道为什么会发生，以及如何解决/处理这个根本问题。

评估：
事件验证是为了验证事件是相关的渲染控件（而不是一些跨站脚本）。由于控件在渲染过程中注册其事件，因此可以在回发或回调期间（通过__doPostBack的参数）验证事件。这可以减少未经授权或恶意回发请求和回调的风险。

参考：MSDN：Page.EnableEventValidation属性

基于上述，我在讨论中引起问题的面临或可能发生的可能情况是：
案例1：如果我们在请求数据中有角括号，那么看起来一些脚本标签正在传递给服务器

可能的解决方案：
在提交表单之前，HTML协助JavaScript编码角括号，即将&替换为<和>with>

  function HTMLEncodeAngularBrackets（someString）
 {
 var modifiedString = someString .replace（ <， &安培; LT;）; 
 modifiedString = modifiedString.replace（>，& gt）; 
 return modifiedString; 
} 
  

案例＃2：如果我们编写客户端脚本来更改客户端中的控件在运行时，我们可能会有一个悬念。一个例子可能是嵌入式控件，其中内部控件注册回发，但由于在外部控制上执行的操作而在运行时隐藏。我在阅读由Carlo撰写的MSDN博客的时候，因为多个表单标签寻找同样的问题。

可能的解决方案：
手动注册控件进行事件验证在页面的Render方法中。

  protected override void Render（HtmlTextWriter writer）
 {
 ClientScript。 RegisterForEventValidation（myButton.UniqueID.ToString（））; 
 base.Render（writer）; 
} 
  

如上所述，其他常见情况之一（其看起来像同一类别）正在构建一个页面，其中一个表单标签嵌入到在服务器上运行的另一个表单标签中。案例3：如果我们在运行时重新定义/实例化每个回发的控件或命令，各自/相关的事件可能会折腾。一个简单的例子可能是在每个pageload（包括回发）上重新绑定一个datagrid。因为在重新绑定时，网格中的所有控件都将有一个新的ID，在datagrid控件触发的事件中，在回发后，控件ID被更改，因此该事件可能无法连接到正确的控件来引发问题。

可能的解决方案：
这可以通过确保每个回发（重新绑定）上不重新创建控件来简单解决。使用页面属性IsPostback可以轻松处理它。如果您想为每个回发创建一个控件，那么有必要确保该ID不被更改。

  protected void Page_Load（object sender，EventArgs e）
 {
 if（！Page.IsPostback）
 {
 //创建控件
 //绑定网格
 
} 
  

结论：
如上所述，一个简单/直接的解决方案在页面指令或Web.config文件中添加enableEventValidation =false，但不建议。根据实施和原因，找到根本原因并相应地应用分辨率。

I have an ASP.net application that works fine in the development environment but in the production environment throws the following exception when clicking a link that performs a postback. Any ideas?

Invalid postback or callback argument. Event validation is enabled using in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Edit: This seems to only be happening when viewed with IE6 but not with IE7, any ideas?

解决方案

Problem description: This is one the common issues that a lot of ASP.NET beginners face, post, and ask about. Typically, they post the error message as below and seek for resolution without sharing much about what they were trying to do.

[ArgumentException: Invalid postback or callback argument. Event validation is enabled using in configuration or <%@ Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.]

Though, error stack trace itself suggests a quick resolution by setting eventvalidation off, it is not a recommended solution as it opens up a security hole. It is always good to know why it happened and how to solve/handle that root problem.

Assessment: Event validation is done to validate if the origin of the event is the related rendered control (and not some cross site script or so). Since control registers its events during rendering, events can be validated during postback or callback (via arguments of __doPostBack). This reduces the risk of unauthorized or malicious postback requests and callbacks.

Refer: MSDN: Page.EnableEventValidation Property

Based on above, possible scenarios that I have faced or heard that raises the issue in discussion are: Case #1: If we have angular brackets in the request data, it looks like some script tag is being passed to server.

Possible Solution: HTML encode the angular brackets with help of JavaScript before submitting the form, i.e., replace "<" with "<" and ">" with ">"

function HTMLEncodeAngularBrackets(someString)
{
var modifiedString = someString.replace("<","&lt;");
modifiedString = modifiedString.replace(">","&gt;");
return modifiedString;
}

Case #2: If we write client script that changes a control in the client at run time, we might have a dangling event. An example could be having embedded controls where an inner control registers for postback but is hidden at runtime because of an operation done on outer control. This I read about on MSDN blog written by Carlo, when looking for same issue because of multiple form tags.

Possible Solution: Manually register control for event validation within Render method of the page.

protected override void Render(HtmlTextWriter writer)
{
ClientScript.RegisterForEventValidation(myButton.UniqueID.ToString());
base.Render(writer);
}

As said, one of the other common scenario reported (which looks like falls in the this same category) is building a page where one form tag is embedded in another form tag that runs on server. Removing one of them corrects the flow and resolves the issue.

Case #3: If we re-define/instantiate controls or commands at runtime on every postback, respective/related events might go for a toss. A simple example could be of re-binding a datagrid on every pageload (including postbacks). Since, on rebind all the controls in grid will have a new ID, during an event triggered by datagrid control, on postback the control ID’s are changed and thus the event might not connect to correct control raising the issue.

Possible Solution: This can be simply resolved by making sure that controls are not re-created on every postback (rebind here). Using Page property IsPostback can easily handle it. If you want to create a control on every postback, then it is necessary to make sure that the ID’s are not changed.

protected void Page_Load(object sender, EventArgs e)
{
if(!Page.IsPostback)
{
// Create controls
// Bind Grid
}
}

Conclusion: As said, an easy/direct solution can be adding enableEventValidation="false" in the Page directive or Web.config file but is not recommended. Based on the implementation and cause, find the root cause and apply the resolution accordingly.

这篇关于无效的回发或回调参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！