Answered by:
"security validation for this page is invalid" After SP1 on infopath browser forms (Isolated what causes it)
-
After 2 days of searching i have finally worked this out. We upgraded our Dev and Test system to SP1 and June CU (dev is now running the latest June CU)
4 of my custom infopath forms started erroring when a post back occured. After trying untold number of thing i have finnaly worked out that this is caused by the People and Group field.
If you have a people and group field on a view and attempt to switch away from it or switch to a view with a people and group field then you get the Error
The security Validation for this page is invalid. Click back in your Web Browser, refresh the page and try your operation again.
Once this happens you infopath session is ruined.
I have created a brand new adminitrator approved form. On the default view just add a few fields. Create a second view with a people and group field. Have a third view with some fields.
Upload the form and add to a library. Open a new version of the form. The form will load. Switch to the third view. The form will load. Switch to the second view and you will get the error.
Anyone have an idea what may cause this and any clue how to resolve before i have to log a call with microsoft and they have to release a third June CU.
Just to add, i have tried to replicate this on a customised list form and cannot recreate. So i would guess this is isolated to administrator approved infopath forms.
Question
Answers
-
Emir: that's not the answer. Disabling security validation is not only a bad idea, it also breaks the silverlight addgallery.aspx control - ie. turn off security validation and you can no longer create new lists/libraries in the browser.
Fix is as below:
1. In the 14 hive, under template/layouts, find the formserver.aspx file.
2. Backup the file and then edit it with any text tool, say, notepad.
3. Under the <body> tag, add the highlighted line of code.
<body runat="server" id="PageBody">
<SharePoint:FormDigest runat="server" />4. Save it. Then the problem should be resolved.
- Proposed as answer by martinjgreen Wednesday, August 3, 2011 4:34 AM
- Marked as answer by Chris Grist Sunday, March 25, 2012 4:38 AM
All replies
-
-
I am now able to confirm this issue on a virgin install of sharepoint SP1 + June CU (second release) with a brand new administrator approved Infopath form that contains a people pick on the default view and a blank second view.
Switching to the second view causes the error.
-
-
-
I have the same problem, but can reproduce it slightly differently - the problem does indeed relate to postbacks on a page with people pickers on, but in my case I'm seeing it where there are attachment fields on the page - try and attach something, it does the postback and you get the error. Remove the people picker from the page, republish, and try and attach it works fine.
From testing I can confirm the problem does not exist on SP1, the problem is with the June CU. The 2nd machine I tested on didn't have project server or web apps installed, so I can also confirm the problem relates to SharePoint Server itself.
Turning off security validation fixes (albeit in a not exactly nice way), but if you turn off security validation addgallery.aspx silverlight control will no longer work - you'll get a generic silverlight error and will no longer be able to create any lists or libraries through the web interface (designer and object model work fine) - so we're screwed either way :)
-
-
-
-
This is due to a new OnLoad event in the June CU:
http://sharepoint.nauplius.net/2011/07/security-validation-issue-in-forms.html
http://sharepoint.nauplius.net -
Emir: that's not the answer. Disabling security validation is not only a bad idea, it also breaks the silverlight addgallery.aspx control - ie. turn off security validation and you can no longer create new lists/libraries in the browser.
Fix is as below:
1. In the 14 hive, under template/layouts, find the formserver.aspx file.
2. Backup the file and then edit it with any text tool, say, notepad.
3. Under the <body> tag, add the highlighted line of code.
<body runat="server" id="PageBody">
<SharePoint:FormDigest runat="server" />4. Save it. Then the problem should be resolved.
- Proposed as answer by martinjgreen Wednesday, August 3, 2011 4:34 AM
- Marked as answer by Chris Grist Sunday, March 25, 2012 4:38 AM
-
-
That is probably not a solution Microsoft would support as it requires direct modifications to files in the 14 hive.
http://sharepoint.nauplius.net
It came from Microsoft Support. :)I would expect it will be fixed in a future update, but for those of us that need a fix now, it does the job.
-
-
That's G8 you are a life saver...I am also facing the same issue in custom lists where I have my own code behind. I am using a people picker control inside newform.aspx and it errors out when I try to submit the form. Could you please let me know where I need to put these lines to resolve this issue. Thanks again...
-
-
We had a similar problem with a custom made ajax webpart. The webpart started to throw a security validation exception after updating to SP1 and October 2011 CU.
Adding the formdigest token to our masterpage didn't solve the problem.
Adding the formdigest token to the OOTB FormServer usercontrol in the layouts folder did solved the problem.
Since modifying OOTB files in 14 hive isn't really an option for us. We are still waiting to update our production servers. Lets hope for a fix soon.
- Edited by Anders Runge [Denmark] Friday, October 28, 2011 10:25 AM
-
-
I seems the research was done by Karla Ponce. For Security Validation Error.
The work around worked for us. http://www.sharepointwithattitude.com/
Fix is as below:
1. In the 14 hive, under template/layouts, find the formserver.aspx file.
2. Backup the file and then edit it with any text tool, say, notepad.
3. Under the <body> tag, add the highlighted line of code.
<body runat="server" id="PageBody">
<SharePoint:FormDigest runat="server" /> -
-
I seems the research was done by Karla Ponce. For Security Validation Error.
The work around worked for us. http://www.sharepointwithattitude.com/
Fix is as below:
1. In the 14 hive, under template/layouts, find the formserver.aspx file.
2. Backup the file and then edit it with any text tool, say, notepad.
3. Under the <body> tag, add the highlighted line of code.
<body runat="server" id="PageBody">
<SharePoint:FormDigest runat="server" />Another solution could be to set your HttpContext to null before calling the code that triggers the exception. It will trick SharePoint to think the code is executed from a console and therefor don't requires form digest validation. It's a hack but I still think its better than modifying 14 hive or disbale form digest validation on the entier web application.
Industrial inspection cameras | Speed enforcement | Line scan cameras | Machine vision cameras