Как исправить ошибку прокси с SDL Tridion SiteEdit 2009 SP2/3

Question

Когда я впервые захожу на прокси-сайт SiteEdit, все загружается правильно, и я могу включить SiteEdit и нормально взаимодействовать. Однако, если я щелкну по любой из ссылок на странице, выполню простое обновление F5 или введу другой URL-адрес для прокси-сайта напрямую, я получу сообщение об ошибке. На странице ошибок я все еще вижу кнопку "SiteEdit", чтобы включить режим SiteEdit, но за ним (по существу, рамка для прокси-страницы, на которой отображается), у меня есть простое сообщение "Произошла ошибка в прокси".

На сервере диспетчера содержимого я могу просмотреть журнал событий приложений и убедиться, что SiteEdit сообщает об ошибке: "Ошибка чтения из входящего запроса. Ссылка на объект не установлена ​​для экземпляра объекта".

Если я закрываю браузер и затем загружаю страницу, на которую пытался зайти, все работает нормально. Однако, если я обновлюсь или попытаюсь перейти на любую другую страницу (связанную или прямую), я снова получу ошибку. Закройте браузер и повторите...

Кто-нибудь может пролить свет на это? В настоящее время я работаю над обновлением SiteEdit 2009 SP2 до SP3, и эта проблема существует в нашей производственной (SP2) и моей песочнице (SP3) среде. Естественно, что наши редакторы контента не используют SiteEdit (в значительной степени из-за этого), и я надеялся, что обновление SP3 могло бы решить то, что было в его основе (но, очевидно, нет).

Я предполагаю, что IE9 настроен правильно (у меня есть сайт в моей зоне интрасети, у меня установлены соответствующие права доступа к скрипту, разрешены всплывающие окна и т. Д.), Так как он работает для начального рендеринга, но при любой попытке в том же сеансе браузера перейти на другую страницу не удается.

Спасибо за любую информацию, которую вы можете дать.

Answer 1

Прошло несколько недель с тех пор, как я связался со службой поддержки, но в течение нескольких встреч с настройками и настройками в конечном итоге они просили меня отследить в стеке ошибку ссылки на объект.

Это заставило меня поработать с одним из моих коллег (который в последнее время углублялся в ведение журнала Tridion), чтобы настроить конфигурацию ведения журнала, чтобы увидеть результаты трассировки стека. К сожалению, после сообщения о проблеме для поддержки я сбросил среду, над которой я работал (как я также работал над обновлением до Tridion 2011), и когда они сделали этот запрос, SiteEdit не регистрировал в журнале событий приложений, как это было настроено для выполнения. (Я думаю, что это, возможно, проблема с разрешением).

Чтобы получить трассировку стека, мой коллега изменил файл \Tridion\SiteEdit 2009\tridion.logging.config для входа в файл:

<?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>

Как только логирование было настроено для записи в файл, мы смогли увидеть трассировку стека исключения:

Ошибка чтения из входящего запроса.
В экземпляре объекта не задана ссылка на объект.

Компонент: SiteEdit.Proxy
Код ошибки: 0
Пользователь: NT AUTHORITY\IUSR

Информация о StackTrace:
в Tridion.Web.UI.SiteEdit.Proxy.Helper.CopyRequestCookies(запрос HttpRequest, CookieContainer cookieContainer)
в Tridion.Web.UI.SiteEdit.Proxy.Request.RequestFactory.CreateRequest(запрос HttpRequest)
в Tridion.Web.UI.SiteEdit.Proxy.Request.RequestFactory.CreateRequest(запрос HttpRequest)
в Tridion.Web.UI.SiteEdit.Proxy.RedirectModule.context_BeginRequest(Отправитель объекта, EventArgs e)

Так как ошибка ссылки на объект была в методе, названном "CopyRequestCookies", мы решили посмотреть наши куки (что имело смысл, так как закрытие и повторное открытие браузера приводило к тому, что SiteEdit снова работал, но только для одного запроса).

Конечно же, у нас был странный файл cookie, который использовался для простой проверки того, что пользователь включил файлы cookie. Код javascript (который, я думаю, мой разработчик получил где-то в Интернете):

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

Обратите внимание, что cookie не имеет значения (типичный JS будет document.cookie = 'name=value';). Мы думаем, что в логике Proxy, где он передает куки, отправленные для прокси-сайта, на промежуточный сайт, есть некоторый код, который не ожидает куки без значения (в Fiddler вы можете видеть, что куки просто передаются как "CookieTest;"), но он не защищен для обработки сценария.

Изменяя наш код, чтобы применить значение к куки document.cookie = 'CookieTest=true' прокси-сервер SiteEdit работает правильно.