That’s the error that users were experiencing with an InfoPath form in production. The error started to appear with no apparent reason. The form had been working for months, no changes had been applied to it and it didn’t have any custom code. It was a “simple” form with controls and rules to manage the business logic.
Doing some research I found that SP1 and Cumulative Updates were installed on the SharePoint server; also I found some blogs talking about a bug with SP1/CU and Form Services (Giles blog, Joel’s blog)
Scenario:
- SharePoint 2010 SP1 and June Cumulative Updates for Office Server installed on the Server.
- InfoPath 2010 Form deployed to SharePoint 2010 Form Services.
- No custom code
- Form contains attachment controls and Person/Group picker controls (among others)
Behavior:
- When attaching a file to the form (using the InfoPath attachment control), a post back occurs and the following error is thrown:
Description of error:
- June CU introduces a new event for InfoPath forms: OnLoad(), this event causes a Postback to the server and if the form has a PeoplePicker or an Attatchments control, then it will throw a security exception. What needs to happen is to have a security validation both on initial page load as well as Post Back; currently the Form page does not implement a security validation control needed in the postback.
Solution:
As of September 9th 2011, Microsoft has not released any fix to this bug, and the response from the Microsoft support team is that they’re not planning to release a fix anytime soon. The possible workarounds to solve this issue are:
- Disable Security Validation. The Web Page Security Validation feature helps enhance security by imposing a time limit on Web pages when a user submits information to the server. When a user tries to submit information to the server after the validation time-out expires, the user receives an error message. This option is not recommended for security reasons; most of the SharePoint functionality uses Security Validation, and disable it can cause unexpected behaviors.
- Add a security control to the page. As explained above, a security validation has to happen after the postback; to accomplish this we need to update the server page: FormServer.aspx to include the code for the security validation control.
Since Microsoft doesn’t have any solution to this problem yet, we got their approval to implement solution #2:
- Go to the layouts folder under the 14 hive
- Before making any change, do a backup of the page FormServer.aspx
- Open the FormServer.aspx page and location the body tag with the Id PageBody: <body runat=”server” id=”PageBody”>
- Right after this line, insert the following line of code:
<SharePoint:FormDigest runat=”server”/>
- Save file and close
That fixes the issue and now the form is working as expected.
…) hehe, I don’t like to waste time on these little errors, specially when I’m as busy as today.
I’m Karla Ponce, a SharePoint consultant based in Houston. I have been involved in the full life cycle of the software development process and have a great passion for technology and how to apply it to satisfy and improve business operations. One of my passions is SharePoint(of course!) so this blog is created as a way to share my experiences with sharepoint. To know more about me 
