Blog Categories

Subscribe to RSS feed


Forms Services: The “InfoPath Sentinel”

There’s an undocumented feature in InfoPath Forms Services called the "InfoPath Sentinel". It only makes itself known under certain conditions:
  • You must be editing a browser-enabled InfoPath form through Form Services
  • Your browser must be configured to block first-party cookies
  • You must perform a postback, such as saving to a data connection or opening a secondary view
In other words, you must be working with a form that relies on AJAX postbacks while cookies are disabled. When those conditions are true, forms behave oddly.
I first encountered the Sentinel while designing a forms environment for a large decentralized organization. I noticed that while most machines experienced full functionality, others suffered from anomalies when printing, saving, or sometimes even loading browser-enabled InfoPath forms. When performing those actions, the page would just render blank and I never experienced an error.
Most problems occurred on Internet Explorer 6, but a few instances of Firefox and Safari had issues as well. I considered differences between functional and nonfunctional PCs and it took me some time to find a difference:
The less functional machines had the token "&_InfoPath_Sentinel=1" in their query strings. Now, it seems so obvious, but the URLs were usually long enough that the token didn’t appear in my address bar.
Finding a common denominator, I searched for more info about the "Sentinel" parameter. It sounded scary.
InfoPath Sentinel
A few posts online referenced cookie settings, which seemed logical. Certain users cited the error message "The form cannot be displayed in the browser because the use of session cookies has been disabled in the current browser settings. In order to load the form, session cookies must be allowed."
As I dug deeper, it was clear that’s what I was facing. While examining the 12 hive, I found the term "Sentinel" in two Javascript files (Core.js and Postback.js). They both contain a function used to verify cookies are enabled and, if not, redirect to a special page to accommodate the limitation:
Core.js and PostbackBody.js:
function PostbackBody_VerifyCookiesEnabled()
{var objSentinelDetection = document.getElementById("__PerformSentinelDetection");
var fCookiesEnabled = PostbackBody.ReadCookie("_InfoPath_Sentinel") != null;
if (!fCookiesEnabled)
{var strOriginalLocation = window.location.href;
if (objSentinelDetection.value == "2" ||
strOriginalLocation.indexOf("?" + "_InfoPath_Sentinel" + "=") >= 0 ||
strOriginalLocation.indexOf("&" + "_InfoPath_Sentinel" + "=") >= 0 )
{Dialog.ShowFinalMessage(IntlCoreStrings.k_strNoCookiesDefined, false );}
{objSentinelDetection.value = "1";
var strSeperator;
if (strOriginalLocation.indexOf("?") >= 0)
{strSeperator = "&";}
{strSeperator = "?";}
var strnewLocation = strOriginalLocation + strSeperator + "_InfoPath_Sentinel" + "=1";
return false;}}
return true;}
I suspect that this parameter is used within the Microsoft.Office.InfoPath.Server library to specify alternate behavior, such as forcing session state usage instead of form state. I wasn’t able to find any references to the string when disassembling through .NET Reflector. The closest thing I found was a class named "SentinelEntry" within System.Web.Caching.Cache.
Whether or not the InfoPath Sentinel is supposed to work around disabled cookies, it acts as a clear warning that they’re not available.
If anybody has more insight on the InfoPath Sentinel, I’d love to hear it.

Leave a Reply