Основные различия между IIS и ASP.NET Development Server (VB)
При локальном тестировании приложения ASP.NET, скорее всего, вы используете веб-сервер разработки ASP.NET. Однако рабочий веб-сайт, скорее всего, работает на платформе IIS. Существуют некоторые различия между обработкой запросов этими веб-серверами, и эти различия могут иметь важные последствия. В этом руководстве рассматриваются некоторые из более немецких различий.
Введение
Всякий раз, когда пользователь посещает приложение ASP.NET его браузер отправляет запрос на веб-сайт. Этот запрос выбирается программным обеспечением веб-сервера, которое координируется с ASP.NET средой выполнения для создания и возврата содержимого для запрошенного ресурса. I nternet I nformation S ervices (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 Development Server, будут иметь те же права доступа, что и администратор. Однако 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
Примечание
МетодFile.WriteAllText создает новый файл, если он не существует, а затем записывает в него указанное содержимое. Если файл уже существует, его существующее содержимое перезаписывается.
Затем посетите страницу обзора книги Обучение себе ASP.NET 3,5 в 24 часах в среде разработки с помощью сервера ASP.NET Development Server. Если вы вошли на компьютер с учетной записью, которая имеет достаточные разрешения на создание и изменение текстового файла в корневом каталоге веб-приложения, проверка книги будет отображаться так же, как и раньше, но при каждом посещении страницы дата и время, а IP-адрес пользователя сохраняется в LastTYASP35Access.txt файле. Укажите в браузере этот файл; вы увидите сообщение, аналогичное тому, которое показано на рис. 1.
Рис. 1. Текстовый файл содержит дату и время посещения последней проверки книги (щелкните для просмотра полноразмерного изображения)
Разверните веб-приложение в рабочей среде, а затем перейдите на страницу рецензирования книги Teach Yourself ASP.NET 3.5 in 24 Hours . На этом этапе вы увидите страницу рецензирования книги в обычном режиме или сообщение об ошибке, показанное на рисунке 2. Некоторые поставщики веб-узлов предоставляют разрешения на запись для анонимной учетной записи компьютера ASP.NET. В этом случае страница будет работать без ошибок. Однако если поставщик веб-узла запрещает доступ на запись для анонимной учетной UnauthorizedAccessException записи, при попытке страницы записать текущую дату и время в LastTYASP35Access.txt файл возникает TYASP35.aspx исключение.
Рис. 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-адресу для поддержки учетных записей пользователей и определения частей сайта, доступных только для прошедших проверку подлинности пользователей или пользователей, принадлежащих определенной роли.
Примечание
Для тщательного изучения ASP. Проверка подлинности на основе форм, авторизация по 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.configPrivateDocs папке настроен для запрета анонимного доступа, среда выполнения ASP.NET автоматически перенаправляет нас на страницу Login.aspx входа (см. рис. 3). При перенаправлении пользователя на страницу входа ASP.NET включает ReturnUrl параметр querystring, указывающий страницу, которую пользователь пытался просмотреть. После успешного входа пользователя можно вернуться на эту страницу.
Рис. 3. Неавторизованные пользователи автоматически перенаправляются на страницу входа (щелкните для просмотра полноразмерного изображения)
Теперь давайте посмотрим, как это работает в рабочей среде. Разверните приложение и введите прямой URL-адрес в один из PDF-файлов в папке PrivateDocs в рабочей среде. При этом браузеру будет предложено отправить запрос IIS для файла. Так как запрашивается статический файл, IIS извлекает и возвращает файл без вызова среды выполнения ASP.NET. В результате не была выполнена авторизация URL-адреса проверка. Содержимое якобы закрытого PDF-файла доступно всем, кто знает прямой URL-адрес файла.
Рис. 4. Анонимные пользователи могут скачать частные PDF-файлы, введя прямой URL-адрес файла (щелкните для просмотра полноразмерного изображения)
Выполнение Forms-Based проверки подлинности и проверки подлинности по 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 6, вы не сможете использовать встроенную функцию конвейера. Одно из обходных решений — поместить личные документы в папку, которая запрещает доступ по протоколу HTTP (например, App_Data), а затем создать страницу для обслуживания этих документов. Эта страница может называться GetPDF.aspx, и передается имя PDF-файла через параметр querystring. Страница GetPDF.aspx сначала проверяет, имеет ли пользователь разрешение на просмотр файла, и, если да, будет использовать Response.WriteFile(filePath) метод для отправки содержимого запрошенного PDF-файла обратно запрашиваемого клиента. Этот метод также подходит для IIS 7, если вы не хотите включать интегрированный конвейер.
Сводка
Веб-приложения в рабочей среде размещаются с помощью программного обеспечения веб-сервера IIS корпорации Майкрософт. Однако в среде разработки приложение может размещаться с помощью IIS или сервера разработки ASP.NET. В идеале одно и то же программное обеспечение веб-сервера следует использовать в обеих средах, так как при использовании другого программного обеспечения в набор добавляется другая переменная. Однако простота использования сервера ASP.NET Development Server делает его привлекательным выбором в среде разработки. Хорошей новостью является то, что между IIS и сервером ASP.NET Development Server существует лишь несколько фундаментальных различий, и если вы знаете об этих различиях, вы можете принять меры, чтобы убедиться, что приложение работает и работает одинаково независимо от среды.
Счастливое программирование!
Дополнительные материалы
Дополнительные сведения по темам, рассматриваемым в этом руководстве, см. в следующих ресурсах:
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по