Основные различия между IIS и ASP.NET Development Server (C#)
При локальном тестировании приложения 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 void Page_Load(object sender, EventArgs e)
{
string filePath = Server.MapPath("~/LastTYASP35Access.txt");
string contents = string.Format("Last accessed on {0} by {1}",
DateTime.Now.ToString(), Request.UserHostAddress);
System.IO.File.WriteAllText(filePath, contents);
}
Примечание
МетодFile.WriteAllText создает новый файл, если он не существует, а затем записывает в него указанное содержимое. Если файл уже существует, его существующее содержимое перезаписывается.
Затем перейдите на страницу обзора книги Обучение себе ASP.NET 3.5 за 24 часа в среде разработки с помощью сервера разработки ASP.NET Development Server. Если вы вошли на компьютер с учетной записью, которая имеет достаточные разрешения на создание и изменение текстового файла в корневом каталоге веб-приложения, рецензирование книги будет таким же, как и раньше, но при каждом посещении страницы дата и время и IP-адрес пользователя сохраняются в LastTYASP35Access.txt файле. Укажите в браузере этот файл; Должно появиться сообщение, аналогичное показанное на рис. 1.
Рис. 1. Текстовый файл содержит дату и время последнего посещения рецензирования книги (щелкните для просмотра полноразмерного изображения)
Разверните веб-приложение в рабочей среде, а затем перейдите на размещенную страницу обзора книги Learn Yourself ASP.NET 3.5 в 24 часа . На этом этапе вы увидите страницу рецензирования книги в обычном режиме или сообщение об ошибке, показанное на рисунке 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 Development Server заключается в том, как они обрабатывают запросы статического содержимого. Каждый запрос, поступающий на сервер разработки 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"?>
<?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 Development Server для файла. Сервер разработки 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.
Жіберу және пікірді көру