Основные различия между IIS и сервером разработки ASP.NET (VB)

Скотт Митчелл

Скачать в формате PDF

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

Введение

Каждый раз, когда пользователь посещает приложение ASP.NET его браузер отправляет запрос на веб-сайт. Этот запрос выбирается программным обеспечением веб-сервера, которое координируется с средой выполнения ASP.NET для создания и возврата содержимого запрошенного ресурса. ИнтернетIнформационные Службы (IIS) — это набор служб, которые предоставляют общие функции на основе Интернета для серверов Windows. IIS является наиболее часто используемым веб-сервером для ASP.NET приложений в рабочих средах; Скорее всего, это программное обеспечение веб-сервера, используемое поставщиком веб-узла для обслуживания приложения ASP.NET. IIS также можно использовать в качестве программного обеспечения веб-сервера в среде разработки, хотя это подразумевает установку IIS и правильное его настройку.

Сервер разработки ASP.NET является альтернативным вариантом веб-сервера для среды разработки; он поставляется и интегрирован в Visual Studio. Если веб-приложение не настроено на использование СЛУЖБ IIS, сервер разработки ASP.NET автоматически запускается и используется в качестве веб-сервера при первом посещении веб-страницы из Visual Studio. Демонстрационные веб-приложения, которые мы создали в руководстве Определение файлов, которые необходимо развернуть, были веб-приложениями на основе файловой системы и не были настроены для использования с IIS. Поэтому при посещении любого из этих веб-сайтов из Visual Studio используется сервер разработки ASP.NET.

В идеальном мире среда разработки и производства будет идентична. Однако, как мы говорили в предыдущем руководстве, это не редкость для сред, имеющих разные параметры конфигурации. Использование другого программного обеспечения веб-сервера в средах добавляет другую переменную, которую необходимо учитывать при развертывании приложения. В этом руководстве рассматриваются основные различия между IIS и сервером разработки ASP.NET. Из-за этих различий существуют сценарии, в которых код, который выполняется безупречно в среде разработки, создает исключение или ведет себя по-разному при выполнении в рабочей среде.

Различия контекста безопасности

Всякий раз, когда программное обеспечение веб-сервера обрабатывает входящий запрос, он связывает этот запрос с определенным контекстом безопасности. Эти сведения о контексте безопасности используются операционной системой для определения допустимых действий запросом. Например, страница ASP.NET может содержать код, который записывает сообщение в файл на диске. Чтобы эта страница ASP.NET выполнялись без ошибок, контекст безопасности должен иметь соответствующие разрешения на уровне файловой системы, а именно разрешения на запись в этом файле.

Сервер разработки ASP.NET связывает входящие запросы с контекстом безопасности текущего пользователя, вошедшего в систему. Если вы вошли на рабочий стол в качестве администратора, ASP.NET страницы, обслуживаемые сервером разработки ASP.NET, будут иметь те же права доступа, что и администратор. Однако ASP.NET запросы, обрабатываемые службами IIS, связаны с определенной учетной записью компьютера. По умолчанию учетная запись компьютера сетевой службы используется службами IIS версии 6 и 7, хотя поставщик веб-узлов может настроить уникальную учетную запись для каждого клиента. Кроме того, поставщик веб-узла, скорее всего, предоставил ограниченные разрешения для этой учетной записи компьютера. Чистый результат заключается в том, что у вас могут быть веб-страницы, которые выполняются без ошибок в среде разработки, но создают исключения, связанные с авторизацией, при размещении в рабочей среде.

Чтобы показать этот тип ошибки в действии, я создал страницу на веб-сайте "Книжные обзоры", который создает файл на диске, в котором хранится самая последняя дата и время, когда кто-то просматривал обзор книги Учитесь ASP.NET 3.5 за 24 часа. Чтобы продолжить, откройте ~/Tech/TYASP35.aspx страницу и добавьте следующий код в Page_Load обработчик событий:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As  System.EventArgs) Handles Me.Load

    Dim filePath As  String = Server.MapPath("~/LastTYASP35Access.txt")

    Dim contents As  String = String.Format("Last accessed on {0} by {1}", _

                                 DateTime.Now.ToString(), Request.UserHostAddress)

     System.IO.File.WriteAllText(filePath, contents)

End Sub

Затем перейдите на страницу обзора книги "Обучение себе" ASP.NET 3.5 в 24 часах в среде разработки с помощью сервера разработки ASP.NET. Предположим, что вы вошли в свою учетную запись на компьютере, имея соответствующие разрешения для создания и изменения текстового файла в корневом каталоге веб-приложения. Рецензия на книгу отображается так же, как и прежде, но каждый раз, когда пользователь посещает страницу, дата, время и IP-адрес пользователя сохраняются в LastTYASP35Access.txt файле. Откройте этот файл в браузере, и вы увидите сообщение, похожее на то, которое показано на рис. 1.

Рис. 1. Текстовый файл содержит дату и время последнего посещения обзора книги (нажмите, чтобы просмотреть изображение в полном размере)

Разверните веб-приложение в рабочую среду, а затем посетите страницу обзора книги Teach Yourself ASP.NET 3.5 in 24 Hours, которая размещена на сервере. На этом этапе должна отображаться либо страница рецензий на книги в обычном режиме, либо сообщение об ошибке, показанное на рис. 2. Некоторые поставщики услуг хостинга предоставляют разрешения на запись анонимной учетной записи машины ASP.NET, в таком случае страница будет работать без ошибок. Однако если поставщик веб-узла запрещает доступ на запись для анонимной учетной записи, UnauthorizedAccessException то при попытке страницы записать текущую дату и время в TYASP35.aspx файл возникает LastTYASP35Access.txt исключение.

Рис. 2. Учетная запись компьютера по умолчанию, используемая службами IIS, не имеет разрешений на запись в файловую систему (щелкните, чтобы просмотреть полноразмерное изображение)

Хорошая новость заключается в том, что большинство поставщиков веб-узлов имеют какой-то инструмент разрешений, который позволяет указать разрешения файловой системы на веб-сайте. Предоставьте учетной записи анонимного ASP.NET права на запись в корневой каталог, а затем снова посетите страницу обзора книги. (При необходимости обратитесь к поставщику веб-узла за помощью по предоставлению разрешений на запись учетной записи по умолчанию ASP.NET.) На этот раз страница должна загружаться без ошибок и LastTYASP35Access.txt файл должен быть успешно создан.

Здесь важно отметить, что поскольку сервер разработки ASP.NET действует в ином контексте безопасности, чем IIS, возможно, что ваши ASP.NET страницы, которые работают с файловой системой, читают из или записывают в журнал событий Windows, а также читают или записывают в реестр Windows, будут функционировать правильно в среде разработки, но могут вызывать исключения на производственной среде. При создании веб-приложения, которое будет развернуто в общей среде размещения веб-сайтов, не считывайте или записывайте в журнал событий или реестр Windows. Кроме того, обратите внимание на любые ASP.NET страницы, которые считываются или записываются в файловую систему, так как может потребоваться предоставить права на чтение и запись в соответствующих папках в рабочей среде.

Различия в обслуживании статического содержимого

Еще одно основное различие между IIS и сервером разработки ASP.NET заключается в том, как они обрабатывают запросы статического содержимого. Каждый запрос, поступающий на сервер разработки ASP.NET( для страницы ASP.NET, изображения или файла JavaScript, обрабатывается средой выполнения ASP.NET. По умолчанию IIS вызывает только исполняемую среду ASP.NET, когда запрос поступает для ресурса ASP.NET, такого как веб-страница ASP.NET, веб-сервис и т. д. Запросы на статическое содержимое — изображения, CSS-файлы, файлы JavaScript, PDF-файлы, ZIP-файлы и подобные — извлекаются службами IIS без участия среды выполнения ASP.NET. (Можно указать IIS работать со средой выполнения ASP.NET при обслуживании статического содержимого; см. раздел в этом руководстве «Выполнение проверки подлинности Forms-Based и проверки подлинности URL-адресов в статических файлах с помощью IIS 7» для получения дополнительной информации.)

Среда выполнения ASP.NET выполняет ряд шагов по созданию запрошенного содержимого, включая проверку подлинности (идентификацию запрашивающего пользователя) и авторизацию (определение того, имеет ли запроситель разрешение на просмотр запрошенного содержимого). Популярная форма проверки подлинности — это проверка подлинности на основе форм, при которой пользователь определяется путем ввода учетных данных ( обычно имени пользователя и пароля) в текстовые поля на веб-странице. После проверки учетных данных веб-сайт сохраняет файл cookie билета проверки подлинности в браузере пользователя, который отправляется с каждым последующим запросом на веб-сайт и используется для проверки подлинности пользователя. Кроме того, можно указать правила авторизации URL-адресов , которые определяют, какие пользователи могут или не могут получить доступ к определенной папке. Многие веб-сайты ASP.NET используют проверку подлинности на основе форм и авторизацию URL-адресов для поддержки учетных записей пользователей и определения частей сайта, доступных только для пользователей, прошедших проверку подлинности или пользователей, принадлежащих определенной роли.

Рассмотрим веб-сайт, поддерживающий учетные записи пользователей с помощью авторизации на основе форм и имеющий папку, которая, используя авторизацию URL-адреса, настроена только для разрешения прошедших проверку подлинности пользователей. Представьте, что эта папка содержит ASP.NET страницы и PDF-файлы, и что намерение заключается в том, что только прошедшие проверку подлинности пользователи могут просматривать эти PDF-файлы.

Что произойдет, если посетитель пытается просмотреть один из этих PDF-файлов, введя URL-адрес непосредственно в адресной строке браузера? Чтобы узнать, давайте создадим новую папку на сайте проверки книги, добавьте некоторые PDF-файлы и настройте сайт для использования авторизации URL-адреса, чтобы запретить анонимным пользователям посещать эту папку. Если скачать демонстрационное приложение, вы увидите, что я создал папку с именем PrivateDocs и добавил PDF-файл из моих руководств по безопасности веб-сайтов (как подходит!). Папка PrivateDocs также содержит файл, указывающий правила авторизации для Web.config URL, чтобы запретить анонимным пользователям:

<?xml version="1.0"?>

<configuration>

    <system.web>

         <authorization>

            <deny  users="?" />

         </authorization>

     </system.web>

</configuration>

Наконец, я настроили веб-приложение для использования проверки подлинности на основе форм, обновив файл Web.config в корневом каталоге, заменив:

<authentication mode="Windows" />

С:

<authentication mode="Forms" />

Используя сервер разработки ASP.NET, перейдите на сайт и введите прямой URL-адрес для одного из PDF-файлов в адресной строке браузера. Если вы скачали веб-сайт, связанный с этим руководством, URL-адрес должен выглядеть примерно так: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf

При вводе этого URL-адреса в адресную строку браузер отправляет запрос на сервер разработки ASP.NET для файла. Сервер разработки ASP.NET передает запрос в среду выполнения ASP.NET для обработки. Так как мы еще не вошли в систему, и так как Web.config в PrivateDocs папке настроен запрет анонимного доступа, среда выполнения ASP.NET автоматически перенаправляет нас на страницу Login.aspx входа (см. рис. 3). При перенаправлении пользователя на страницу входа ASP.NET включает параметр строки запроса ReturnUrl, который указывает на страницу, которую пользователь пытался просмотреть. После успешного входа пользователя на эту страницу можно вернуться.

Рис. 3. Неавторизованные пользователи автоматически перенаправляются на страницу входа (щелкните, чтобы просмотреть изображение полного размера)

Теперь давайте посмотрим, как это работает в продакшене. Разверните приложение и введите прямой URL-адрес для одного из PDF-файлов в папке PrivateDocs в рабочей среде. Это предложит браузеру отправить запрос IIS для файла. Так как статический файл запрашивается, службы IIS извлекают и возвращают файл без вызова среды выполнения ASP.NET. В результате не выполнена проверка авторизации URL-адресов; Содержимое якобы закрытого PDF-файла доступно любому, кто знает прямой URL-адрес файла.

Рис. 4. Анонимные пользователи могут скачать частные PDF-файлы, введя прямой URL-адрес файла (щелкните, чтобы просмотреть изображение полного размера)

Выполнение проверки подлинности на основе форм и проверки подлинности URL-адресов в статических файлах с помощью IIS 7

Существует несколько методов, которые можно использовать для защиты статического содержимого от несанкционированных пользователей. IIS 7 представил интегрированный конвейер, который объединяет рабочий процесс IIS с рабочим процессом среды выполнения ASP.NET. В кратком окне можно указать службам IIS вызывать модули проверки подлинности и авторизации среды выполнения ASP.NET все входящие запросы (включая статическое содержимое, например PDF-файлы). Обратитесь к поставщику веб-узла, чтобы узнать, как настроить веб-сайт для использования интегрированного конвейера.

После настройки IIS для использования встроенного конвейера добавьте следующую разметку Web.config в файл в корневом каталоге:

<system.webServer>

      <modules>

          <add  name="FormsAuthenticationModule"  type="System.Web.Security.FormsAuthenticationModule" />

          <remove  name="UrlAuthorization" />

          <add  name="UrlAuthorization"  type="System.Web.Security.UrlAuthorizationModule" />

          <remove  name="DefaultAuthentication" />

          <add  name="DefaultAuthentication"  type="System.Web.Security.DefaultAuthenticationModule" />

      </modules>

</system.webServer>

Эта разметка указывает IIS 7 использовать модули аутентификации и авторизации на основе ASP.NET. Повторно разверните приложение и затем снова откройте PDF-файл. На этот раз, когда IIS обрабатывает запрос, он предоставляет логику проверки подлинности и авторизации среды выполнения ASP.NET возможность проверить запрос. Так как только прошедшие проверку подлинности пользователи могут просматривать содержимое в PrivateDocs папке, анонимный посетитель автоматически перенаправляется на страницу входа (вернитесь на рис. 3).

Сводка

Веб-приложения в рабочей среде размещаются с помощью программного обеспечения веб-сервера IIS Майкрософт. Однако в среде разработки приложение может размещаться с помощью IIS или сервера разработки ASP.NET. В идеале одно и то же программное обеспечение веб-сервера должно использоваться в обеих средах, так как при использовании другого программного обеспечения в смеси добавляется другая переменная. Однако простота использования сервера разработки ASP.NET делает его привлекательным выбором в среде разработки. Хорошая новость заключается в том, что существует лишь несколько фундаментальных различий между IIS и сервером разработки ASP.NET, и если вы знаете об этих различиях, вы можете предпринять шаги, чтобы обеспечить работу приложения и функции одинаково независимо от среды.

Счастливое программирование!

Дальнейшее чтение

Дополнительные сведения о разделах, описанных в этом руководстве, см. в следующих ресурсах:

• интеграция ASP.NET с IIS 7.0
• Использование проверки подлинности ASP.NET форумов со всеми типами контента в IIS 7 (видео)
• Веб-серверы в Visual Web Developer