ASP.NET: история любви и история ненависти

В целом я хорошо отношусь к ASP.NET, однако иногда нелепые проблемы с IIS заставляют меня испытывать к этому продукту настоящую ненависть. Самое печальное в этой истории «любви-ненависти» состоит в том, что способ устранения основной причины моего негативного отношения к IIS по сути очень прост. Основная причина состоит в том, что технология слишком сильно меняется от одной версии Windows к другой (и даже от обновления к обновлению). Расскажу вам о моей последней «стычке» с ASP.NET.

Новый сервер разработки

Я решил обновить сервер разработки, перейдя с виртуальной машины под Windows Server 2008 R2 на виртуальную машину под Windows Server 2012 R2. В целом обновление прошло гладко, и, так как я уже вовсю использовал Windows Server 2012 R2, у меня было ощущение абсолютного успеха. Пришлось выполнить диагностику ошибок при перемещении копий приложений MVC 3, MVC 4 и MVC 5 со старого сервера (с IIS 6.5) на новый (с IIS 8.5), но эта работа предполагалась изначально и заняла примерно час.

К сожалению, настроив и запустив сервер разработки, я забыл создать образ самой виртуальной машины (чтобы сохранить состояние операционной системы и настройки нижнего уровня). Спустя примерно неделю контроллер RAID на моем хосте VMware перегрелся, и вместе с ним «сгорела» эта виртуальная машина (как и две другие тестовые машины). У меня, конечно, были резервные копии всех данных, но машина вместе со своими настройками пропала безвозвратно.

История диагностики

К счастью, так как совсем недавно я развертывал новый экземпляр Windows Server 2012 R2 в качестве сервера разработки, мне было нетрудно сделать это снова. Установка новой машины с IIS,. NET Framework и SQL Server с последующим восстановлением по всем резервным копиям заняла менее 30 минут активной работы.

Вот тут-то и началось самое интересное. В то время как мои сайты запускались без проблем, еще один сайт, на котором я активно работаю в последнее время, при каждой попытке доступа к корневой папке постоянно перенаправлял меня по маршруту/account/login. Какое-то время я пытался выяснить, не связано ли наблюдаемое явление с недавними изменениями в файле Startup.Auth.cs в приложении MVC 5. Кроме того, у меня не получалось воспроизвести аналогичную проблему на рабочей станции при работе с IIS Express. Это случалось только с IIS 8.5 на сервере разработки — там, где неделю назад, также с IIS 8.5, этого не происходило.

В ходе дальнейших изысканий я установил, что могу без проблем проследовать по заданному маршруту (например,/home/index) на новом сервере, но любая попытка перейти к корневой папке сайта и предоставить процессу маршрутизации направить меня по «маршруту по умолчанию» оканчивается неудачей при использовании IIS 8.5. И все это при отсутствии проблем в локальном варианте с IIS Express, а также с IIS 8.5 ранее.

Я подумал, что, возможно, сбились настройки процесса маршрутизации на этой машине или что у меня просто неправильно указан маршрут по умолчанию. При помощи установленного отладчика маршрутов (www.nuget.org/packages/routedebugger/) я убедился в том, что маршруты, прописанные мною вручную, работают отлично; однако я по-прежнему не мог получить доступ к корневой папке проблемного сайта: система перенаправляла меня по маршруту/account/login и сообщала, что этот ресурс не существует.

Я отключил Startup.Auth.cs, убрав проверку подлинности из приложения, с тем лишь результатом, что в локальном варианте с IIS Express все, как и прежде, продолжало отлично работать, тогда как на сервере разработки я стал теперь получать ошибку HTTP 401. Это означало, что процесс OWIN подключения в моем приложении (на сервере разработки) отлавливал код 401 и совершенно справедливо пытался меня перенаправить и предоставить мне возможность пройти проверку подлинности.

В результате поиска в Интернете информации об ошибке HTTP 401 я наконец-то выяснил, в чем дело (http://stackoverflow.com/questions/13279593/401?unauthorized-access-is-denied-due-to-invalid-credentials/28836927#28836927). В какой-то момент при второй установке сервера разработки произошло переключение IIS с проверки подлинности по удостоверению пула приложений Application Pool Identity (на основании своего многолетнего опыта считаю это оптимальным методом) на проверку по имени пользователя IUSR. А поскольку я предоставил разрешение доступа к папкам на моих сайтах пользователю IIS APPPOOL\<имя сайта>, а не IUSR, проблемный сайт получал HTTP 401 при доступе к корневой папке (но не при переходе по прописанным в явном виде маршрутам), тогда как в предыдущем варианте сервера разработки с Windows Server 2012 R2 готовые настройки IIS указывали на использование удостоверения пула приложений для анонимного доступа.

Полагаю, что при первом обновлении сервера разработки я использовал Windows Server 2012 R2, а во второй раз, скорее всего, взял. iso-образ Windows Server 2012 R2 Update 1. По-видимому, одно из «преимуществ» Update 1 состоит в том, что в этой версии полностью переписана схема подключения при проверке подлинности. Вот почему я так не люблю IIS — за то, что от версии к версии и от обновления к обновлению постоянно меняются схемы безопасности. И если только вы не следите постоянно за публикациями в блоге группы разработчиков IIS, то едва ли будете знать об изменениях в модели безопасности и потратите много сил и времени, пока не выясните, что ваши проблемы связаны не с приложениями, а с безопасностью и вызваны очередным обновлением.

Как исправить положение

Мне, вероятно, не следовало браться за статью, не справившись с негативными эмоциями, вызванными этой ситуацией. С другой стороны, я потратил около часа на анализ возникшей проблемы, в то время как установка и ввод в действие нового сервера с нуля заняли всего лишь 30 минут. Данная проблема и сама по себе была крайне неприятной, но одна лишь мысль о том, что я буду вынужден тратить время на исследование какого-либо аспекта IIS всякий раз, когда придется иметь дело с новым сайтом, уже приводит меня в негодование.

Оставляя в стороне эмоции, замечу, что может существовать простое средство, способное помочь в этой ситуации. Таким средством может быть программа выявления различий. Можно также воспользоваться программой, которая будет преобразовывать всю информацию, касающуюся исследуемого сайта IIS (в моем случае, IIS 8.5), в текст, который затем можно будет сопоставить (например, с помощью WinMerge) с работающим вариантом (в моем случае с IIS Express). Это позволит довольно быстро выявлять явные различия в моделях безопасности. Без этого взаимодействие с IIS, когда дело доходит до переноса сайтов или перехода на новый хост, будет сводиться к трудоемким изысканиям на основе догадок и предположений. Остается надеяться, что группа разработчиков IIS (или какая-либо добрая душа) создаст такой инструмент, а до этого момента я неизбежно буду время от времени переживать вспышки ненависти к IIS.