Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page
For example Web Forms is checking that drop down values are part of values that were provided from the server side to avoid tampering. You can disable this when it make sense (at the page or control level if I remember).
Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page
This error means
This error is due to 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.
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.
Based on the above, possible scenarios that I have faced or heard that raise 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.
Solution: HTML encodes the angular brackets with the help of JavaScript before submitting the form, i.e., replace “<” with “<” and “>” with “>”
function HTMLEncodeAngularBrackets(someString)
{
var modifiedString = someString.replace("<","<");
modifiedString = modifiedString.replace(">",">");
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.
Solution: Manually register control for event validation within Render method of the page.
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 IDs are changed and thus the event might not connect to correct control raising the issue.
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 IDs are not changed.
.NET forums are moving to a new home on Microsoft Q&A, we encourage you to go to Microsoft Q&A for .NET for posting new questions and get involved today.
Member
47 Points
1656 Posts
Invalid postback or callback argument
Jul 17, 2020 10:17 AM|aspfun|LINK
What this message mean? How to fix it?
Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page
All-Star
20953 Points
4984 Posts
Re: Invalid postback or callback argument
Jul 17, 2020 11:23 AM|asteranup|LINK
Anup Das Gupta
Visit My Blog
You can also connect with me in LinkedIn
All-Star
48570 Points
18081 Posts
Re: Invalid postback or callback argument
Jul 17, 2020 12:07 PM|PatriceSc|LINK
Hi,
Or see https://www.jardinesoftware.net/2012/02/06/asp-net-tampering-with-event-validation-part-1/ and see first if it is supposed to happen.
For example Web Forms is checking that drop down values are part of values that were provided from the server side to avoid tampering. You can disable this when it make sense (at the page or control level if I remember).
Contributor
3370 Points
1409 Posts
Re: Invalid postback or callback argument
Jul 20, 2020 03:26 AM|samwu|LINK
Hi aspfun,
This error means
This error is due to 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.
Reference: Page.EnableEventValidation Property
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.
Based on the above, possible scenarios that I have faced or heard that raise 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.
Solution: HTML encodes the angular brackets with the help of JavaScript before submitting the form, i.e., replace “<” with “<” and “>” with “>”
function HTMLEncodeAngularBrackets(someString) { var modifiedString = someString.replace("<","<"); modifiedString = modifiedString.replace(">",">"); 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.
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); }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 IDs are changed and thus the event might not connect to correct control raising the issue.
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 IDs are not changed.
protected void Page_Load(object sender, EventArgs e) { if(!Page.IsPostback) { // Create controls // Bind Grid } }More information about this question you can refer to this link: Invalid Postback or Callback Argument
Hope this can help you.
Best regards,
Sam