From feeling to insight

Today I found myself running into the ‘famous’ “The security validation for this page is invalid” error and it cost me quite some stress figuring out what went wrong, and why I wasn’t allowed to do what I wanted, a simple change to a user profile.

The thing is that everything worked fine, until I actually added the UserProfile.Commit() to apply the changes to my profile. So after some searching the web for something that could help me further (besides the run with elevated privileges), and some help from my colleague Peter we found the following article: The security validation for this page is invalid.

Basically the idea is: forget the AllowUnsafeUpdates(); and add a FormDigestControl to the page you are working on, as you can see it only takes a reference: 

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

And a control:

<SharePoint:FormDigest runat=server/>

Further info can be found on the mentioned blog.

I just ran into a nice SharePoint problem that is being described and resolved over here. Apparently there is a job trying to access your HOSTS file, in order to add some lines for the Search, and if it doesn’t have sufficient rights it complains about it. Whenever you decide to add users and give them ‘fulltrust’ it just deletes the host file..

So whenever you see your log filling up with:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance

Reason: Access to the path ‘C:\WINDOWS\system32\drivers\etc\HOSTS’ is denied.

Or:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance

Reason: Access to the path ‘C:\WINDOWS\system32\drivers\etc\HOSTS’ is denied.

Make sure that COMPUTERNAME\WSS_ADMIN_WPG has modify permissions on your HOSTS file. Whenever the HOSTS file is already gone, just create a new empty file with notepad and save it as HOSTS without an extension. (Make sure to add the COMPUTERNAMWSS_ADMIN_WPG with modify permissions after that again).

So, failed, now that explains a lot. I while ago i had this error and it got me looking almost everywhere trying to find a solution. Posts about invalid characters in the manifest.xml didn’t provide me a solution since i had no special characters anywhere. However they got me in the right direction, the encoding of the manifest.xml should be UTF-8, and for some reason I found out it wasn’t.

So whenever you have the error “failed to extract the cab file in the solution”, do three things

• make sure you don't have any special characters in your manifest.xml (or any other solution file).
• check the encoding and make sure it’s set to UTF-8.
• according to this post the error can be provoked by having two files with the same name in either the feature.xml, the elementmanifest.xml or the solution.ddf

You can easily check the encoding by opening the file in your notepad.exe and then do a save-as. It will have a property Encoding that should be UTF-8:

Then of course rebuild your .wsp, and deploy it again.

Have you ever spent time trying to debug a masterpage? Like every SharePoint developer I spent my days on the SharePoint platform, and since ‘everything’ you see in SharePoint is based on masterpages, it would be nice if they do what they should. However a lot of customers require customized masterpages, and a lot of these masterpages work just fine, and if they don’t you can easily debug them, or not.

Last week we had a nice issue; in IE6 (yea IE6) our masterpage didn’t show the navigation controls in the edit navigation page. Seems out the masterpage been missing a three divs:  

    <div id="zz1_CurrentNav_Data" style="display:none;"></div>

    <div id="zz1_TopNavigationMenu_Data" style="display:none;"></div>

    <div id="zz2_CurrentNav_Data" style="display:none;"></div>

Adding those divs (even with a display:none) will fix a lot of these errors. And there is a nice way to find out what other divs are required by SharePoint to show all data.  Since often you can see the error in the lower left of the screen (often something like: Scripts loading …), the underlying issue can be found in the JavaScript.  Just browse to the Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033 (make sure to change the 1033 to your regional code, so in my case it would be 1043 and make a copy of the BFORM.js, then edit the original one.  On rule 12418 you can find the var named L_PleaseWaitForScripts_Text this var is used to display errors, now start at the top of your document and search for it. You will see that its only used in the SPOnError_HandleErrors function, where you can find:

                     {
                                window.status=L_PleaseWaitForScripts_Text;
                     }

Just add a simple alert above the window.status that displays the msg passed to your function.

Next time you open the page you want you will get a nice popup containing your error. Nice feature to debug your pages. (Though its only executed when the window.status is not complete)