IIS - как лучше всего обслуживать другую версию сайта для разных пользователей.

Question

Это не касается контроля версий для источника. Это требование бизнеса и того, как он взаимодействует с различными поставщиками, поэтому я пытаюсь разработать наилучший способ его настройки. По сути, нам нужно обслуживать другую основную версию сайта, в зависимости от того, кто ее ударил - и не отображают эту версию в URL-адресе. Вот как это работает прямо сейчас:

Сайт ASP.NET MVC 4 работает на IIS 7. В настоящее время он настроен на сайт по умолчанию в IIS с приложениями под ним. Каждое приложение является версией сайта. Когда исходный запрос попадает на сайт, он запускается через собственный фильтр ISAPI. Этот фильтр захватывает, по сути, переменную идентификатора пользователя из URL-адреса и использует ее для запроса базы данных SQL. Эта база данных связывает идентификатор пользователя с версией, которая должна быть подана (приложение в IIS), и добавляет ее в начало URL-адреса. Таким образом, http://site.com/1 становится http://site.com/2.1.0.0/1, тем самым указывая на правильный каталог в IIS. Затем в пределах сайта пользовательские HtmlHelpers используются для удаления версии из строки URL, когда создаются привязные ссылки или кнопки и т. Д. Когда пользователь нажимает на одну из этих ссылок, она повторяется.

Это кажется излишне сложным. Я бы не хотел использовать пользовательские HtmlHelpers и просто молча перенаправить запросы на другой виртуальный каталог/физический путь в IIS.

Для альтернативы, мы рассмотрели:

• Использование URL Rewrite в IIS - но это требует версии, чтобы прийти в первоначальном запросе, и конечный пользователь не будет знать, что ,
• Использование пользовательского HttpHandler - но для этого требуется, чтобы веб-сайт уже ударил - запрос уже прошел в IIS. Может быть, я недостаточно знаю, чтобы заставить его работать.
• Попытка не переписывать URL-адрес, а только виртуальный каталог/физический путь с фильтром ISAPI, но, похоже, мы не можем использовать этот крючок.
• Создайте пользовательский HttpModule, который вызывает HttpContext.RewritePath(), но столкнулся с проблемами с маршрутами MVC и HtmlHelpers, так же, как если бы HttpModule ничего не делал.

У меня нет кода для обмена, на самом деле - это патентованный. Я ищу больше теории. Как было бы создано такое безумное устройство для управления версиями веб-сайтов?

Answer 1

После многого другого, мы нашли ответ. Проблема с комментариями Гарата выше заключается в том, что, хотя правила исходящего трафика могут переписываться Html.ActionLink и Html.BeginForm, они ничего не могут сделать для RedirectToRoute или RedirectToAction и более. Исходящие правила обрабатывают только сформированный HTML-контент и изменяют его перед отправкой обратно в браузер. Исходящие правила также несовместимы с gzip, что понятно, но раздражает.

Короче говоря, мы создали пользовательский поставщик перезаписи, который использует соединение SQL, чтобы вытащить версию и вернуть правильный URL. Мы также подключились к возможности перезаписи URL-адресов IIS для отправки настраиваемых переменных сервера, чтобы предотвратить запрос к базе данных более одного раза за сеанс. Вот как это работает:

1. запрос попадет в URL IIS Rewrite модуля
2. сначала проверяют правила для значения печенья и, если он существует, переписывает URL, основанный на том, что и прекращает обработку дополнительных правил.
3. Если cookie не существует, он вызывает пользовательский поставщик, который использует SQL для перезаписи URL-адреса.
4. Второе правило также устанавливает пользовательскую переменную сервера, переданную в заголовке в версию.
5. Веб-сайт проверяет эту переменную заголовка, а если установлен, создается файл cookie с версией.
6. Промыть и повторить.

Ссылки, которые помогли нам:

• http://www.iis.net/learn/extensions/url-rewrite-module/developing-a-custom-rewrite-provider-for-url-rewrite-module
• http://www.iis.net/learn/extensions/url-rewrite-module/using-custom-rewrite-providers-with-url-rewrite-module
• http://archive.msdn.microsoft.com/rewriteextensibility
• http://forums.iis.net/t/1186281.aspx
• http://forums.iis.net/t/1188570.aspx/1
• http://www.iis.net/learn/extensions/url-rewrite-module/setting-http-request-headers-and-iis-server-variables
• http://www.iis.net/learn/extensions/url-rewrite-module/url-rewrite-module-configuration-reference#UsingServerVars

Надеется, что это может помочь кому-то еще в будущем.

Сторона примечания. Пользовательский поставщик перезаписи должен установить целевой .NET 2.0, который не указан в первой ссылке выше.