Конфигурация IIS 8.5 вызывает проблему с созданием динамической ссылки Sitefinity 12.1 (ASP.NET .NET 4.7.2)

Я использую IIS 8.5 на Windows Server 2012 R2. Это тестовый сервер, и у меня на нем работают 3 сайта: Dev, QA и Staging.

Проблема в QA. Приложение ASP.NET Sitefinity, работающее там, разрешает неправильное доменное имя при динамическом создании ссылок. В частности, он использует www в домене вместо qa. Итак, https://qa.myexamplesite.com - это желаемая ссылка, но она создает https://www.myexamplesite.com.

Существует www.myexamplesite.com, но он размещен на совершенно другой машине. Также код приложения не содержит ссылок на домен.

Dev и Staging работают нормально. Я изменил физический путь QA, чтобы указать на Dev, но QA все еще не работает. Я изменил физический путь Dev, чтобы он указывал на код приложения QA, но Dev не ломается - по-прежнему работает нормально. На данный момент я достаточно уверен, что в IIS есть проблема с конфигурацией, но пока мне не удалось ее найти. Мне также не удалось воссоздать проблему на моем локальном компьютере.

Вот подробные сведения о конфигурации из файла ApplicationHost без какой-либо конфиденциальной или несущественной информации:

<applicationPools>
    <add name="DefaultAppPool" />
    <add name=".NET v4.5 Classic" managedRuntimeVersion="v4.0" managedPipelineMode="Classic" />
    <add name=".NET v4.5" managedRuntimeVersion="v4.0" />
    <add name="dev.myexamplesite.com" autoStart="true" />
    <add name="staging.myexamplesite.com" autoStart="true" />
    <add name="qa.myexamplesite.com" />
    <applicationPoolDefaults managedRuntimeVersion="v4.0">
        <processModel identityType="ApplicationPoolIdentity" />
    </applicationPoolDefaults>
</applicationPools>

  <sites>
        <site name="dev.myexamplesite.com" id="1" serverAutoStart="true">
            <application path="/" applicationPool="dev.myexamplesite.com">
                <virtualDirectory path="/" physicalPath="S:\Dev\myexamplesite" />
                <virtualDirectory path="/App_Data/Sitefinity/Search" physicalPath="S:\Dev\SitefinitySearch" />
            </application>
            <bindings>
                <binding protocol="http" bindingInformation="*:80:dev.myexamplesite.com" />
                <binding protocol="https" bindingInformation="*:443:dev.myexamplesite.com" sslFlags="0" />
            </bindings>
        </site>
        <site name="staging.myexamplesite.com" id="3" serverAutoStart="true">
            <application path="/" applicationPool="staging.myexamplesite.com">
                <virtualDirectory path="/" physicalPath="S:\Staging\myexamplesite" />
                <virtualDirectory path="/App_Data/Sitefinity/Search" physicalPath="S:\Staging\SitefinitySearch" />
            </application>
            <bindings>
                <binding protocol="http" bindingInformation="*:80:staging.myexamplesite.com" />
                <binding protocol="https" bindingInformation="*:443:staging.myexamplesite.com" sslFlags="0" />
            </bindings>
        </site>
        <site name="qa.myexamplesite.com" id="2" serverAutoStart="true">
            <application path="/" applicationPool="qa.myexamplesite.com">
                <virtualDirectory path="/" physicalPath="S:\QA\myexamplesite" />
            </application>
            <bindings>
                <binding protocol="https" bindingInformation="*:443:qa.myexamplesite.com" sslFlags="0" />
                <binding protocol="http" bindingInformation="*:80:qa.myexamplesite.com" />
            </bindings>
        </site>       
        <siteDefaults>
            <logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />
            <traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />
        </siteDefaults>
        <applicationDefaults applicationPool="DefaultAppPool" />
        <virtualDirectoryDefaults allowSubDirConfig="true" />
    </sites>

Я проработал ресурсы, чтобы попытаться найти, где может существовать эта проблема. Приложение использует специальные методы Sitefinity для динамического создания ссылок, поэтому мне не удалось точно определить, какой метод они используют. Вот некоторые из странного поведения, которые мне удалось документировать.

Я могу обновить IIS, flushdns и т. Д., Но поведение не меняется. Я перезапустил сервер, но проблема осталась.

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

Это похоже на проблему с кешированием IIS, но я не могу отследить, где это настроено. Я не могу обнаружить настроенного кэширования вывода.

(в сторону) Если это полезно - код приложения вызывает этот метод из пера библиотеки Sitefinity с открытым исходным кодом: https://github.com/Sitefinity/feather/blob/master/Telerik.Sitefinity.Frontend/Mvc/Helpers/HyperLinkHelpers.cs

Он специально вызывает GetFullPageUrl (строка 149). Однако я обнаружил, что это ограниченное использование, поскольку оно вызывает UrlPath, который является членом проприетарного Telerik.Sitefinity.Web.

Я ценю любую информацию, ресурсы, направление, мысли или упреки по этой проблеме. Спасибо


person RobotOptimist    schedule 02.12.2019    source источник


Ответы (2)


Можете ли вы перейти в Администрирование> Настройки> Дополнительно> Система> Настройки URL-адреса сайта и посмотреть, установлен ли флажок «Включить нестандартные настройки URL-адреса сайта» и не задано ли в поле «Хост» жестко привязанные к любому из других сайтов.

Если да, возможно, вы захотите исправить это.

person Veselin Vasilev    schedule 03.12.2019
comment
Это то, что я уже делал, и в нем не было жестко закодированных сайтов, отличных от стандартных. Я бы предпочел, чтобы это была проблема конфигурации Sitefinity, поскольку ее можно было легко исправить из настроек, но я думаю, что это не так: 1) Изменение физического пути IIS на совершенно другую базу рабочего кода не решает проблему 2) Изменение физического пути IIS для экземпляра dev на неработающий экземпляр qa не вызывает у разработчика проблемы с голосованием за поддержку, поскольку это будет ответом для подавляющего большинства людей, у которых будет аналогичная проблема. - person RobotOptimist; 03.12.2019

Я хочу частично отдать должное Веселину Васильеву, поскольку он был на правильном пути. Итак, вот что произошло и как мы это исправили.

В то время, когда стала возникать ошибка, у нас был запущен другой экземпляр Sitefinity, который указывал на базу данных QA. Sitefinity по какой-то причине начала ссылаться на часть конфигурации db после этого события. Непонятно, что это за триггер именно, или что позволяло ему работать так долго до этого события с этой неверной информацией.

Рассматриваемая конфигурация db - это таблица с именем sf_sites. Существует запись с именем live_url, которую необходимо изменить, чтобы это исправить. Мы восстановили производственный экземпляр Sitefinity в наших тестовых средах для тестирования обновления Sitefinity, не зная, что база данных Sitefinity хранит записи доменных имен.

Конфигурация, о которой говорил Веселин, переопределяет это свойство live_url (хотя я никогда не мог заставить это переопределение работать должным образом). Странно то, что мы восстановили тестовую базу данных с производственной базой данных несколько месяцев назад и никогда не сталкивались с проблемой. Проблема возникла только после того, как у нас появилось несколько сайтов, обращающихся к одной и той же базе данных, и даже после удаления второго сайта она не исчезла.

В любом случае, обновление таблицы sf_sites помогло. Добавьте это в свой контрольный список, если вам нужно скопировать базу данных Sitefinity одной среды в новую среду.

person RobotOptimist    schedule 03.12.2019
comment
О, так это был экземпляр с несколькими сайтами. Фактически вы можете изменить действующий URL-адрес из пользовательского интерфейса Sitefinity, нет необходимости вручную обновлять базу данных. - person Veselin Vasilev; 04.12.2019
comment
Мы не планировали, что это будет экземпляр с несколькими сайтами, но другой человек тестировал функцию и решил запустить другой экземпляр IIS и указать его на ту же базу данных, но да, это определенно сработало. Спасибо за помощь Веселин - person RobotOptimist; 04.12.2019