How to fix proxy error with SDL Tridion SiteEdit 2009 SP2/3

Question

When I first access the proxy website for SiteEdit, everything loads up correctly and I can enable SiteEdit and interact fine. However, if I click any of the links on the page, do a simple F5 refresh or directly type in a different URL for the proxy site, I receive an error. On the error page I still see the "SiteEdit" button to enable the SiteEdit mode, but behind it (essentially the frame for the proxied page to display in) I have a simple "An error has occured in the proxy" message.

On the content manager server I can look in the Application event log and see that the error SiteEdit is reporting is "Error reading from the incoming request. Object reference not set to an instance of an object."

If I close my browser and then load the page I was attempting to go to, everything works fine. However, if I refresh or try to go to any other page (linked or direct) I once again get the error. Close the browser and repeat...

Can anyone shed any light on this? I'm currently working on upgrading SiteEdit 2009 SP2 to SP3 and this is a problem that exists in our production (SP2) and my sandbox (SP3) environment. Naturally our content editors don't use SiteEdit (pretty much because of this) and I was hoping the SP3 upgrade might have resolved whatever was at the heart of it (but apparently hasn't).

I assume I have IE9 configured properly (I have the site in my Intranet Zone, I have the appropriate script permissions set, I have pop-ups allowed, etc) since it works for the initial rendering, but any attempt in the same browser session to go to another page fails.

Thanks for any insight you can give.

Answer 1

It's been a few weeks since I contacted support, but over the course of several back & forths with configs and settings they eventually asked me for a stack trace of the object reference error.

This led me to work with one of my colleagues (who had been delving into Tridion's logging of late) to tweak the logging configuration in order to see the stack-trace output. Unfortunately, after reporting the problem to support I reset the environment I was working on (as I've also been working on upgrading to Tridion 2011) and when they made this request SiteEdit was not logging in the Application event log as its configured to do (I'm thinking it's possibly a permission issue).

To get the stack-trace, my colleague changed the \Tridion\SiteEdit 2009\tridion.logging.config to log to a file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" />
  </configSections>
  <loggingConfiguration name="Logging Application Block" tracingEnabled="true" defaultCategory="General" logWarningsWhenNoCategoriesMatch="false">
    <listeners>
      <add name="Log File" fileName="C:\Tridion\log\SiteEdit.log" formatter="Tridion Text Formatter" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" traceOutputOptions="None" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" />
    </listeners>
    <formatters>
      <add template="{timestamp} &lt;{win32ThreadId}&gt; {message}" type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" name="Trace Text Formatter" />
      <add template="{message}&#xA;&#xA;Component: {keyvalue(component)}&#xA;Errorcode: {keyvalue(errorcode)}&#xA;User: {keyvalue(username)}&#xA;&#xA;{keyvalue(stacktrace)}" type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" name="Tridion Text Formatter" />
    </formatters>
    <categorySources>
      <add switchValue="All" name="General" />
    </categorySources>
    <specialSources>
      <allEvents switchValue="All" name="All Events">
        <listeners>
          <add name="Log File" />
        </listeners>
      </allEvents>
      <notProcessed switchValue="All" name="Unprocessed Category" />
      <errors switchValue="All" name="Logging Errors &amp; Warnings" />
    </specialSources>
  </loggingConfiguration>
</configuration>

Once logging was configured to write out to a file, we were able to see the exception's stack-trace:

Error reading from the incoming request.
Object reference not set to an instance of an object.

Component: SiteEdit.Proxy
Errorcode: 0
User: NT AUTHORITY\IUSR

StackTrace Information Details:
at Tridion.Web.UI.SiteEdit.Proxy.Helper.CopyRequestCookies(HttpRequest request, CookieContainer cookieContainer)
at Tridion.Web.UI.SiteEdit.Proxy.Request.RequestFactory.CreateRequest(HttpRequest request)
at Tridion.Web.UI.SiteEdit.Proxy.Request.RequestFactory.CreateRequest(HttpRequest request)
at Tridion.Web.UI.SiteEdit.Proxy.RedirectModule.context_BeginRequest(Object sender, EventArgs e)

Since the object reference error was in a method entitled "CopyRequestCookies" we decided to look at our cookies (which made sense since closing and reopening the browser caused SiteEdit to work again, but only for a single request).

Sure enough, we had a strange cookie that was being used to simply validate a user had cookies turned on. The javascript code (which I think my developer got from somewhere online) was:

document.cookie = 'CookieTest';
if (document.cookie == "") {
    $("form").append('<div class="master-error"><p>Cookies are not enabled</p></div>');
}

Notice the cookie does not have a value (typical JS would be document.cookie = 'name=value';). We're thinking that in the Proxy logic where it is passing the cookies submitted for the proxy site to the staging site, there is some code that is not anticipating a cookie with no value (in Fiddler you can see that the cookie is simply passed as "CookieTest;") but is not defensively coded to handle the scenario.

By changing our code to apply a value to the cookie document.cookie = 'CookieTest=true' the SiteEdit proxy is working properly.