Iis создание приложений


Содержание

Как настроить сервер IIS для запуска ISAPI приложения?

Этот пост для тех, кто хочет узнать как настраивать IIS для работы ISAPI приложений и как их потом запускать. Предполагается, что ISAPI приложение уже создано и нам нужно только настроить IIS и запустить наше приложение на localhost

IISInternet Information Server – программа-сервер, от компании Microsoft (у меня на борту Windows 8.1 стояла версия IIS 8.5, единственное, нужно было её активировать).

Как настроить сервер IIS для запуска ISAPI приложения?

Теперь одна из самых важных вещей – настройка сервера IIS. Об этом я уже много и подробно писал в длинной и подробной статье “Delphi+UniGui. Пишем первый “Hello World” под WEB. Легко и просто”, поэтому в принципе, материал той статьи подойдет в большинстве своем и для этой статьи. Пэтому, часть того материала, я просто копирую.

Основные шаги по настройке IIS

Добавляем новый пул приложений

Назовем его, скажем, MyWebApps, версия среды – без управляемого кода, режим конвейера – встроенный. Делаем все как на картинке ниже

Заходим в настройки…

Включаем поддержку 32-разрядных приложений

Далее, настраиваем параметры перезапуска

Жмем Ок, выходим из этого окна.

Далее идем в сайты и добавляем новое приложение

Выбираем псевдоним, пул приложений, физический путь. Внимание, в этом месте вместо псевдонима MyWebApplication – поставьте myapp, чтобы пример выше из этого поста заработал.

Выбираем физический путь, например C:\WebAps

Далее, 2 раза кликаем на MyWebApplication на дереве слева

Далее, убеждаемся что ISAPI-dll находится в группе Enabled (Включен), если в группе Disabled (Выключен), то…

Включаем, если отключен

Далее
Далее, добавляем приложение в число разрешенных…

Выбираем физический путь

В итоге должно получиться так…

Как обратиться к ISAPI приложению в браузере?

Первый вариант – напрямую

Далее, можно попробовать открыть браузер и набрать в адресной строке

Настройка IIS¶

В версии 8.3.0 способ связки с IIS (всех версий старше 5.1) претерпел разительные изменения. Теперь вместо соединения IIS IPI.Manager на основе FastCGI используется наш собственный ISAPI модуль. Это позволило сделать настройку намного проще, саму работу IPI.Manager гибче и стабильнее.

Версии IIS выходили вместе с разными версиями Windows по следующей схеме:

Версия IIS Версии Windows Поддержка IPI.Manager
IIS 5.1 Windows XP 32bit не поддерживается
IIS 6.0 Windows XP 64bit Windows Server 2003 (32/64bit) поддерживается
IIS 7.0 Windows Vista 32/64bit Windows Server 2008 (32/64bit) поддерживается
IIS 7.5 Windows 7 32/64bit Windows Server 2008 R2 (32/64bit) поддерживается

Таким образом IPI.Manager может работать в паре с IIS всех версий, начиная с IIS 6.0.

Для работы IPI.Manager под Windows XP 32bit можно использовать либо встроенный веб-сервер, либо Apache 2.

Описание¶

Здесь и дальше употребляются следующие псевдо-термины:

: папка с профилем, который Вы должны были создать ранее (например, C:ipimy_profile).

: аккаунт, под которым будет запускаться Windows-служба IPI.Manager.

: аккаунт, под которым будет запускаться пул приложения IPI.Manager в IIS

Принцип связи с IIS следующий: с одной стороны запускается сервис с IPI.Manager, который слушает соединения на каком-либо порту (на любом =)). Информация о созданном сервисе (включая порт) сохраняется в

/share/settings.yaml и используется как для запуска сервиса, так и для соединения к нему модуля ISAPI. Затем с другой стороны в IIS вставляется модуль ipimanager_isapi.dll и docroot сайта ставится в

/share/htdocs . Наш ISAPI модуль смотрит на docroot и ищет

/share/settings.yaml . Когда находит — видит, что сервис IPI.Manager запущен на порту NNNN и пытается соединится с ним.

Таким образом, краткий порядок действий для настройки таков (ниже эти шаги будут расписаны более подробно):

  1. Настроить права доступа к файлам
  2. Настроить и запустить сервис IPI.Manager
  3. (опционально) Создать новый сайт в IIS
  4. Установить docroot сайта в IIS на

/share/htdocs

  • Добавить в IIS модуль ipimanager_isapi.dll
  • Настройка прав доступа к файлам¶

    В дальнейшем у вас будет запускаться два процесса — один будет сервисом Windows, другой будет запускать IIS при создании пула приложения IPI.Manager. По умолчанию IIS запускает приложения от имени NETWORK_SERVICE, а сервис Windows запускает от имени System Logon Account. Если вы не особо заботитесь о безопасности — Вас это волновать не должно, но лучше создать отдельного пользователя, скажем, IPI.Manager User и прописать его в обоих местах.

    В любом случае права на доступ к файлам должны быть следующими:

    Пользователь, под которым запускается сервис:

    чтение и запись в папку профиля (

    только чтение в папку с системными файлами IPI.Manager ( C:\Program Files\IPI\IPI.Manager\ )

    Пользователь, под которым IIS создаёт пул приложений

    только чтение в папку профиля (

    только чтение в папку с системными файлами IPI.Manager ( C:\Program Files\IPI\IPI.Manager\ )

    Если же у вас всё запускаться планируется под 1 пользователем — значит он должен иметь права на чтение и запись в папку профиля и только чтение в папку C:\Program Files\IPI\IPI.Manager\

    В случае, если отдельного пользователя не создавать, это означает что пользователю NETWORK_SERVICE нужно дать права на чтение и в папку C:\Program Files\IPI\IPI.Manager\ и в папку

    Настройка и запуск сервиса IPI.Manager¶

    Нужно перейти в папку профиля в консоли ( cmd.exe ) и выполнить:

    Порт можно выбрать любой. Но как правило, это порты выше 10000-го и те, которые не заняты ничем другим. Консоль после этого можно закрыть — сервис будет работать самостоятельно.

    Сервис будет создан со следующими параметрами:

    пользователь: локальный системный аккаунт

    запуск: автоматический (при старте Windows)

    действия при исключениях: ничего не делать

    С умолчательными параметрами всё будет работать тоже, но для тонкой и правильной настройки любой уважающий себя администратор захочет ещё кое-что изменить. Это все изменяемо стандартными средствами Windows. Для изменения нужно открыть свойства сервиса (My computer (Мой компьютер)-> Правый клик -> Manage (Управление) -> Services and Applications -> Services). Там в списке сервисов найти IPI.Manager Command runfcgi -> правый клик -> Properties (свойства).

    Во-первых целесообразно изменить действия операционной системе при сбое сервиса. Во всех случаях — перезапуск:

    Во-вторых хорошо бы запускать сервис не от имени системного пользователя, а от имени какого-либо другого. Мы советуем создать специального пользователя.

    После любых изменений сервис нужно перезапускать. Это можно делать как средствами Windows (либо в диалоговом окне свойств, либо через sc.exe ), либо средствами комманды ipi-admin :

    Установка IIS7¶

    Если IIS ещё не установлен, его нужно установить. Для этого достаточно добавить роль веб-сервера с нужными параметрами.

    Далее обязательно нужно выбрать сервис ISAPI Extensions:

    Добавление модуля ipimanager_isapi.dll¶

    У вас уже должен быть установлен пакет IIS для Windows!

    IIS 6¶

    • Windows XP 64bit
    • Windows Server 2003 32/64bit

    Откройте менеджер настроек IIS (Пуск -> Выполнить -> inetmgr).

    Создайте новый веб-сайт:

    Описание — любое (лучше всего использовать имя будущего домена, например ipimanager.mycompany.ru). Домашнюю папку укажите как

    \share\htdocs . Если установить неправильно — впоследствии вам будет об этом сообщено. Естественно, в виде ошибки =).

    Затем создайте новый пул приложений. Назовите его IPI.Manager App Pool.

    Вы можете так же изменить учётную запись пула (по-умолчанию это будет NETWORK_SERVICE, то есть процесс IPI.Manager ISAPI будет запускаться от имени этого пользователя). При этом нужно обязательно добавить эту учётную запись в группу IIS_WPG, иначе ничего работать не будет. Если всё сделаете правильно, и процесс ipimanager_service.exe и w3wp.exe (это процесс IIS) будут запущены от имени одного пользователя:

    Затем откройте свойства сайта. На вкладке Home Directory сначала удалите приложение, а затем создайте заново (кликнуть на Remove, затем на Create). В качестве пула приложений для только чт созданного приложения выберите созданный вами ранее пул IPI.Manager App Pool. Название приложения укажите как IPI.Manager ISAPI Handler. Нажмите Применить и потом зайдите в настройки приложения (кнопка Configuration там же, рядом).

    В блоке Wildcard application maps нажмите Insert. В появившемся диалоговом окне выберите файл C:Program FilesIPIIPI.Manageripimanager_isapi.dll. Уберите галочку Verify that file exists и попрбуйте сохранить. Если диалоговое окно недовольно скажет, что имена файлов с пробелами нужно обрамлять кавычками — сделайте это (т.е. получится что-то вроде «C:\Program Files\IPI\IPI.Manager\ipimanager_isapi.dll» ). Сохраните всё.

    В старых версиях IPI.Manager использовался хендлер fcgiext.dll. Если он есть в списке Wildcard application maps, нужно его оттуда удалить.

    Затем в диалоговом окне управления IIS (Пуск -> Выполнить -> inetmgr) кликните правой кнопкой по Web Service Extensions и выберите Add new Web service extension. . В появившемся окне задайте любое имя расширению (например, IPI.Manager ISAPI Handler), в качестве требуемых файлов добавьте C:\Program Files\IPI\IPI.Manager\ipimanager_isapi.dll и статус расширения выберите как Allowed (Разрешённое).

    Теперь не забудьте запустить сам веб-сайт

    После этого можете попробовать открыть сайт в браузере (для начала, http://localhost/). По идее всё будет работать сразу же.

    Возможные ошибки будут такими же как и для IIS7 / IIS7.5, о них смотрите в разделе ниже.

    IIS7 / IIS7.5¶

    • Windows Vista 32/64bit
    • Windows Server 2008 32/64bit
    • Windows 7 32/64bit
    • Windows Server 2008 R2 32/64bit

    Откройте менеджер настроек IIS (Пуск -> Выполнить -> inetmgr).

    Создайте новый веб-сайт:

    Название сайта — любое. Application pool — тот, который вы создали ранее. Удобнее всего использовать название будущего домена (например, manager.mycompany.ru). Домашнюю папку укажите как

    \share\htdocs . Если установить неправильно — впоследствии вам будет об этом сообщено. Естественно, в виде ошибки =). Выключите галочку Start web site immidiately.

    Зайдите в список пулов приложений, там будет только что созданный пул специально для нового сайта. Откройте его базовые опции и выключите ASP.NET

    Откройте расширенные опции и разрешите запуск 32-битных приложений

    Откройте Handler Mappings

    Добавьте Wildcard script map

    В старых версиях IPI.Manager использовался хендлер fcgiext.dll . Если он есть в списке Handler Mappings, нужно его оттуда удалить.

    На вопрос — создавать ли исключение для ISAPI/CGI, ответье Yes (Да):

    Теперь откройте ISAPI/CGI Restrictions

    создание приложений IIS с помощью библиотеки Microsoft.Web.Administration создает два приложения вместо одного

    November 2020

    6.7k раз

    Я пытаюсь автоматизировать создание приложений IIS , и для этого я использую Microsoft.Web.Administration библиотеку. Вот часть кода я использую:

    IISHelper.cs

    А вот основной код, который вызывает методы из упомянутого выше класса IISHelper

    После выполнения этого кода я получаю успешно создано приложение с сайтом и соответствующим пулом приложений под IIS, но когда я выбрать «View Application» в меню недавно созданный пул приложений я вижу там два приложения, но я уверен, что там должно быть только одно приложение. Я работаю над этим, чтобы избежать создания двух приложений, но не может найти путь. Вот картина, иллюстрирующая, что:

    Так вот мой вопрос: почему после вышеупомянутого кода два приложения создаются и как изменить код, чтобы избежать этой проблемы?

    1 ответы

    Каждый сайт должен включать в себя «Root Application» , которая является то , что вы видите в качестве второго приложения. В основном , когда вы запрашиваете ваш сайт выше как « http://example.com/ » (или что — то имя хоста вы установили в привязок) вы будете запрос от этого корня приложения, кроме того , вы создаете / TestApp , который будет запрашиваться при называя ‘ http://example.com/TestApp ‘. При создании сайта , и вы обеспечить физический путь он внутренне создает корневое приложение «/» для него. Чтобы убедиться в этом вы можете открыть файл % WINDIR% \ system32 \ Inetsrv \ applicationHost.config.

    Технически, что вы видите, это правильно, но Вы не могли бы на самом деле хотите новое приложение? и нужно только корневое приложение? Вам действительно нужно / TestApp быть в URL?

    Национальная библиотека им. Н. Э. Баумана
    Bauman National Library

    Персональные инструменты

    IIS (Internet Information Services)

    Internet Information Services
    Разработчики: Microsoft
    Постоянный выпуск: 10 / 29 July 2015 года ; 4 years ago ( 2015-07-29 )
    Состояние разработки: Active
    Написана на: C++ (язык программирования) [1]
    Операционная система: Windows NT
    Локализация: Same languages as Windows
    Тип ПО: Web server
    Лицензия: Part of Windows NT (same license)
    Веб-сайт iis .net

    IIS (англ. Internet Information Services ) является Visual Basic приложением, которое располагается на веб-сервере и отвечает на запросы браузера. Приложение IIS использует HTML для представления своего пользовательского интерфейса и использует скомпилированый код Visual Basic для обработки запросов и реагирования на события в браузере. Для пользователя приложение IIS представляется рядом страниц HTML. Для разработчика приложение IIS состоит из особого типа объекта, называемого WebClass, который в свою очередь, содержит ряд ресурсов, называемых webitems. WebClass выступает в качестве центрального функционального блока приложения, обрабатывающего данные из браузера и отправляющего информацию пользователям. Разработчик описывает ряд процедур, которые определяют, каким образом WebClass отвечает на эти запросы. webitems являются HTML-страницами и другими данными, которые WebClass может отправить в браузер в ответ на запрос.

    Содержание

    Архитектура

    Internet Information Services (IIS) 7 и выше обеспечивает архитектуру обработки запросов, которая включает в себя:

    • Служба активации процесса Windows (WAS), который позволяет сайтам использовать отличающиеся от HTTP и HTTPS протоколы.
    • Веб-движок сервера, который может быть изменен путем добавления или удаления модулей.
    • Интегрированные конвейеры обработки запросов от IIS и ASP.NET.

    Компоненты

    IIS содержит несколько компонентов, которые выполняют важные функции для приложений и ролей веб-сервера в Windows Server® 2008 (IIS 7.0) и Windows Server 2008 R2 (IIS 7.5). Каждый компонент имеет функции, такие как прослушивание запросов к серверу, управление процессами и чтение файлов конфигурации. Эти компоненты включают в себя обработчики протокола, такие как HTTP.sys и службы, такие как World Wide Web Publishing (служба WWW) и службы активации процесса Windows (WAS).

    Internet Information Server (IIS) имеет свой собственный ASP.NET Process Engine для обработки запроса ASP.NET. Способ настройки приложения ASP.NET зависит от того, какая версия IIS приложения используется.

    Internet Information Server (IIS) включает в себя набор программ для создания и администрирования веб-приложений, поисковых систем, а также поддержку для написания веб-приложений, обеспечивающих доступ к базам данных, таким как SQL Server. IIS позволяет настроить компьютер в качестве веб-сервера и предоставляет функциональные возможности для разработки и развертывания веб-приложений ASP.NET на сервере. Кроме того, возможно установить параметры безопасности для конкретного веб-сайта для конкретных пользователей и компьютера для того, чтобы защитить его от несанкционированного доступа.


    По заявлениям разработчиков, IIS повышает доступность веб-сайтов и приложений при одновременном снижении системного администрирования и стоимости развертывания. IIS 7.5 поддерживает HTTP, HTTPS, FTP, FTPS, SMTP и NNTP.

    Ключевые особенности

    • Встроенные расширения
      • WebDAV и FTP
      • Фильтрация запросов
      • Модули администрирования
    • Усовершенствования управления
      • Анализатор соответствия рекомендациям
      • Windows PowerShell провайдер и cmdlets
      • Ведение журнала конфигурации и трассировки
    • Улучшения хостинга приложений
      • Управляемые учетные записи служб
      • Hostable веб-ядро
      • Трассировка неудачных запросов для FastCGI
    • Улучшения .NET поддержки для Server Core

    Установка

    • Нажмите кнопку Пуск и выберите Панель управления.
    • На панели управления выберите Программы, а затем Включение и отключение компонентов Windows.
    • В диалоговом окне «Компоненты Windows» нажмите Службы IIS, а затем кнопку ОК.

    Конфигурирование

    Настройка веб-узла по умолчанию: При установке IIS настроен для использования в качестве веб-узла по умолчанию; тем не менее может потребоваться изменить некоторые настройки. Чтобы изменить основные параметры для веб-узла и имитировать действия, которые требуются для настройки Apache в первый раз с помощью файла конфигурации:

    1. Войдите в систему на компьютере веб-сервера с правами администратора.
    2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
    3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
    4. Щелкните правой кнопкой мыши веб-узел, который необходимо настроить, на левой панели и выберите команду Свойства.
    5. Перейдите на вкладку веб-узел .
    6. В поле Описание введите описание веб-узла.
    7. Введите адрес Internet Protocol (IP) для веб-узла или оставьте значение по умолчанию все (не назначено) .
    8. Измените порт протокола управления передачей (TCP), соответствующим образом.
    9. Перейдите на вкладку Домашний каталог.
    10. Чтобы использовать папку на локальном компьютере, выберите каталог на данном компьютере и нажмите кнопку Обзор, чтобы найти папку, которую требуется использовать.
    11. Чтобы использовать папку, общий ресурс с другого компьютера в сети, выберите параметр Общая папка другого компьютера и затем введите путь или нажмите кнопку Обзор, чтобы выбрать общую папку.
    12. Нажмите кнопку Чтение предоставить доступ на чтение к папке (обязательно).
    13. Нажмите кнопку ОК, чтобы принять свойства веб-сайта.

    Создание нового веб-узла:

    Чтобы создать новый веб-узел на сервере Apache, необходимо настроить виртуальный узел и настроить отдельные параметры для узла. Если используются службы IIS, можно создать новый веб-узел путем перевода следующих терминов в эквивалентные термины IIS:

    Apache термин Термин IIS
    Корень документа Каталог домашней страницы веб-узла IIS
    Имя_сервера Заголовок узла IIS
    Прослушивание IIS IP-адрес и TCP-порт

    Чтобы создать новый веб-узел в IIS, выполните следующие действия:

    1. Войдите в систему на компьютере веб-сервера с правами администратора.
    2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
    3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
    4. Щелкните Действие, выберите пункт Создать и выберите веб-узел.
    5. После запуска мастера создания веб-узла, нажмите кнопку Далее.
    6. Введите описание веб-узла. Это описание используется для идентификации веб-узла в диспетчере служб Интернета только для внутренних целей.
    7. Выберите IP-адрес для веб-узла. Если выбрать все (без значения), веб-узел будет доступен для всех интерфейсов и всех настроенных IP-адресов.
    8. Введите номер порта TCP, чтобы опубликовать на нем сайт.
    9. Введите имя заголовка узла (реальные имя, которое используется для доступа к этому узлу).
    10. Нажмите кнопку Далее.
    11. Введите путь к папке, которая содержит документы веб-узла, или нажмите кнопку Обзор, выберите папку и нажмите кнопку Далее.
    12. Укажите права доступа для веб-узла и нажмите кнопку Далее.
    13. Нажмите кнопку Готово.

    Изоляция приложений IIS

    Проблемы «песочницы»

    Время от времени каждому администратору приходится развертывать Web-приложения, связанные с пересылкой конфиденциальной информации. Приложение необходимо установить на надежно защищенном сервере таким образом, чтобы никакая другая программа Microsoft IIS не имела доступа к файлам приложения. Эффективные меры позволяют защитить конфиденциальную информацию от злоумышленников и опасных программ, размещенных на одном сервере с конфиденциальной информацией. Я всегда считал, что приложения, нуждающиеся в особенной защите, необходимо размещать на отдельном сервере. Однако нередко администраторам приходится разворачивать защищенные приложения на одном сервере со многими другими программами.

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

    Особенности изолирования

    Желательно сразу предупредить руководителей предприятия о том, что идеальная изоляция приложений не достижима ни на одной из существующих платформ IIS. В частности, полная изоляция приложений в IIS 5.0 невозможна, потому что продукт не проектировался в расчете на использование «песочницы» (sandbox). Важнейшие компоненты и процессоры сценариев, такие как Cold Fusion компании Macromedia, работают в процессе inetinfo.exe, который должен выполняться в контексте учетной записи System. В таких условиях высокий уровень изоляции просто невозможен.

    В IIS 6.0 Web-приложения по умолчанию запускаются в контексте безопасности встроенной учетной записи Network Service. Данный контекст — значительный шаг вперед по сравнению с учетной записью System. Благодаря одному этому улучшению IIS 6.0 — уже явно предпочтительный вариант для размещения Web-сервера. Уделив достаточное внимание деталям, можно обеспечить высокий уровень изоляции приложений на сервере IIS 6.0.

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

    Представление и идентификация процесса

    Для безопасности IIS всегда важно идентифицировать процесс, в котором выполняются приложения. Каждое приложение связано с конкретным экземпляром процесса. Например, если пользователь, зарегистрированный как Joe, запускает notepad.exe, то программа работает под управлением Joe и располагает пользовательскими правами и разрешениями Joe. Как правило, службы выполняются с правами учетной записи System, административные инструменты работают с расширенными правами учетной записи Administrator, а пользовательские программы, такие как Microsoft Office, выполняются с правами запустившего их пользователя. Во всех случаях программа связана со средой исполнения, именуемой также контекстом безопасности.

    Как и другие приложения, IIS для запуска Web-приложений задействует хост-процесс (в зависимости от версии IIS). Хост-процесс оценивает системные ресурсы, используя идентификатор процесса. Например, IIS 6.0 задействует хост-процесс с именем w3wp.exe, который работает с идентификатором процесса Network Service. Однако если w3wp.exe всегда использует Network Service для доступа к файлам, то пользовательские разрешения NTFS теряют свое значение! Каждому файлу и программе требуется только разрешение Network Service для чтения, исполнения или записи (по необходимости), а любые другие разрешения излишни.

    Очевидно, что такой сценарий неприемлем. Требуется более высокий уровень детализации при управлении разрешениями пользователей и групп. Для этой цели IIS не идентифицирует процессы, а представляет (impersonate) пользователя, сравнивая пользовательский маркер доступа, назначенный в ходе аутентификации, с разрешениями NTFS для файла. Таким образом, реализуются пользовательские разрешения.

    Разработчики спроектировали как IIS 6.0, так и IIS 5.0 таким образом, чтобы IIS в большинстве случаев представлял пользователя, но некоторые Web-приложения обходят эту процедуру. Другими словами, программист может составить приложение, которое «обращается к себе» для доступа к системным ресурсам IIS. То есть IIS сверяет разрешения для доступа к системным ресурсам с разрешениями для экземпляра процесса, а не для учетной записи пользователя.

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

    Microsoft ASP.NET — пример приложения, в котором не всегда используется представление. Для активизации представления (я рекомендую сделать это для приложений, не использующих аутентификацию на базе форм) следует выполнить действия, описанные в главе «ASP.NET Impersonation» руководства Microsoft .NET Framework Developer?s Gu >

    Управлять представлением в ASP.NET можно с помощью параметра в файлах .config, однако не так легко убедиться в корректности представления в скомпилированных приложениях. Один из признаков неисправности — приложение работает, только если запущено в контексте учетной записи System. Если разработчики или поставщики настаивают на выполнении приложения в режиме Low application protection в IIS 5.0 или назначают идентификатор LocalSystem пулу приложений, в котором приложение размещено в IIS 6.0, то приложение должно потребовать привилегированного контекста. Это верный признак неполноты представления.

    Другой способ определить, обращается ли приложение к файлам от имени экземпляра процесса или от имени учетной записи пользователя, — задействовать утилиту Filemon.exe компании Sysinternals. Эта бесплатная утилита показывает в реальном времени все обращения к файлам на сервере. Необходимо лишь отменить разрешения Full Control для нужного файла, запустить Filemon и обратиться к файлу, чтобы увидеть запись Access Denied в столбце результатов и имя пользователя, обратившегося к файлу. Процедура показана на экране 1.

    Экран 1. Выяснение тонкостей доступа к файлу с помощью Filemon

    Идентификация процесса чрезвычайно важна для изоляции приложений. Рассмотрим два приложения — защищенное и общедоступное. Если оба приложения работают с одним экземпляром процесса, то разработчик общедоступного приложения может загрузить на сервер программу, которая переключает экземпляр процесса. В данном контексте безопасности программа, работающая в общедоступном приложении, может прочитать весь контент Web-узла из безопасного приложения и даже вызывать размещенные в нем приложения. Самая большая угроза при этом исходит от пользователей, имеющих право загружать на сервер и запускать программы, особенно двоичные исполняемые файлы. Поэтому главную опасность представляют программисты, имеющие доступ к приложениям. Взломщик извне может добиться таких же результатов, успешно проведя атаку с использованием идентификатора процесса общедоступного приложения. Типичный пример — атаки с переполнением буфера. Злоумышленник также может разместить «троянского коня» на рабочей станции программиста и получить привилегированный доступ к серверу или получить доступ методами «социальной инженерии». По этой причине приложения, которые должны работать в контексте учетной записи System или Administrator, нельзя надежно изолировать друг от друга.

    В идеальном случае, решая задачу создания изолированного в «песочнице» приложения, можно применить к Web-контенту разрешения NTFS. В результате получаем экземпляры процессов, связанных с защищенным приложением, и его пользователи — единственные субъекты безопасности, имеющие доступ к контенту. Другими словами, следует убедиться, что разрешения NTFS не дают доступа к экземпляру процесса любому другому Web-приложению. Для этого необходимо знать все идентификаторы процессов, используемые IIS. В IIS 6.0 назначить защищенному приложению уникальный идентификатор достаточно просто (об этом будет рассказано в следующем разделе), а для IIS 5.0 можно руководствоваться таблицей. Таблица применима и к IIS 6.0 при работе в режиме изоляции исполняемого процесса IIS 5.0.

    Изменение идентификаторов процессов

    При выполнении типичного Web приложения в IIS 5.0 можно увидеть три имени процесса, каждое с собственным идентификатором. Inetinfo.exe — главный процесс, который работает в контексте процесса System. IIS использует dllhost.exe, когда приложение настроено на работу в режиме Medium или High Application Protection в IIS Manager и выполняется в контексте пользователя IWAM_servername user (создаваемого в процессе установки IIS). Приложения ASP.NET выполняются в процессе с именем aspnet_wp.exe, который использует в качестве идентификатора процесса учетную запись ASPNET.

    При запуске Web-приложений в Inetinfo с идентификатором процесса System возникает проблема. В случае атаки с переполнением буфера (как было при нападениях Code Red и Nimbda), взломщик получает доступ к самым широким правам на сервере.

    Microsoft не поддерживает работу inetinfo.exe в контексте учетных записей, кроме учетной записи System. Кроме того, несмотря на возможность изменить идентификатор процесса приложений ASP.NET, все приложения ASP.NET выполняются в одном экземпляре aspnet_wp.exe. Лучшее решение для IIS 5.0 — использовать Component Services для настройки идентификатора IWAM для dllhost.exe. Сделав это, необходимо изменить пароль в метабазе и для локальной учетной записи пользователя IWAM. Из-за необходимости специализированных настроек усложняются развертывание, диагностика и администрирование. В результате, а также в силу зависимости от inetinfo.exe (работающей от имени System) не рекомендуется применять IIS 5.0 для изоляции приложений в «песочницах».

    Объединять идентификаторы процессов IIS 6.0 гораздо проще, чем в IIS 5.0. По умолчанию любая программа, запускаемая на сервере IIS 6.0, будет выполняться в контексте учетной записи Network Service, за исключением приложений Common Gateway Interface (CGI), которые работают в собственном контексте пользователя, вызвавшего их. Назначить уникальный идентификатор любому пулу приложений, в котором размещено Web-приложение, можно на вкладке Identity в диалоговом окне свойств пула (экран 2).

    Экран 2. Диалоговое окно Properties пула приложений

    Однако есть одна особенность: учетная запись Network Service — член группы, существующей только в Windows Server 2003 с установленным IIS 6.0, группы IIS_WPG. Как указывается в справочных файлах IIS 6.0, группа IIS_WPG располагает минимальным набором полномочий, необходимых для IIS, и обеспечивает удобный способ использования учетной записи определенного пользователя в качестве идентификатора, не назначая вручную разрешений этому идентификатору. Далее: «В тех случаях когда учетная запись не принадлежит к группе IIS_WPG и не имеет соответствующих разрешений, попытка запуска исполнительного процесса закончится неудачей». Эта цитата не точна и вводит в заблуждение. Идентификатор, присвоенный пулу приложений (экран 2), должен быть членом группы IIS_WPG. Это обязательное условие. Нельзя назначить учетной записи пользователя все необходимые полномочия, так как некоторые из них встроены в группу IIS_WPG и связаны с http.sys.

    Это обстоятельство имеет важное значение для изоляции приложений в IIS 6.0. Следует помнить, что программист может управлять представлением. Все экземпляры процессов (пулы приложений) являются членами группы IIS_WPG, поэтому по умолчанию все Web-приложения могут обращаться к любому контенту на сервере, доступ к которому для IIS_WPG разрешен настройками NTFS.

    Задача администратора здесь простая, но не очевидная: необходимо назначить уникальный экземпляр процесса каждому изолируемому приложению, сделать экземпляр членом группы IIS_WPG и предоставить уникальному экземпляру разрешения NTFS Read и Execute для контента сайта. Нельзя использовать такие группы, как Users, Everyone, Authenticated Users и IIS_WPG для назначения разрешений на Web-сайте, поскольку уникальные экземпляры процесса будут членами этих групп.

    Управление разрешениями для IIS_WPG

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

    Группа IIS_WPG имеет разрешения Full Control в папке IIS Temporary Compressed Files. IIS использует эту папку в тех случаях, когда в IIS Manager активизирован режим сжатия. В результате сжатия IIS записывает сжатые данные в папку IIS Temporary Compressed Files и в ответ на последующие запросы извлекает документы из кэша. Для всех Web-узлов существует только одна папка IIS Temporary Compressed Files, и в соответствии со статьей Microsoft «Using HTTP Compression for Faster Downloads» (http://www.microsoft.com/resources/ documentation/IIS/6/all/techref/en-us/iisRG_PER_26.mspx) группа IIS_WPG должна иметь разрешения Full Control для данной папки. Эта информация противоречит сведениям, приведенным в статье Microsoft «Default permissions and user rights for IIS 6.0» (http://support.microsoft.com/ kb/812614), в которой стандартными разрешениями названы List, Read и Write. В действительности группа IIS_WPG наделена разрешениями Full Control.

    Для изолируемых приложений угрозу представляет любая область, в которой группа IIS_WPG имеет разрешения Full Control. Администратору при управлении сжатием предоставляется следующий выбор.

    • Не использовать сжатия. Чтобы сжатия не было, нужно удалить группу IIS_WPG из числа имеющих разрешения в папке IIS Temporary Compressed Files.
    • Использовать сжатие только для надежно защищенных сайтов. Требуется удалить группу IIS_WPG из числа имеющих разрешения в папке IIS Temporary Compressed Files и назначить разрешения Full Control уникальной учетной записи, созданной для пула приложений.
    • Использовать сжатие только для сайтов, отличных от защищенного сайта. Сделать это проще всего в папке IIS Temporary Compressed Files: запретить доступ с Full Control экземпляру процесса, назначенного пулу приложений, в котором находится защищенное приложение. В такой конфигурации сжатие могут использовать все приложения, за исключением защищенного.

    Легко заметить, что группа IIS_WPG также имеет разрешения Full Control в папке \%windir%system32inetsrvASP compiled templates. В статье Microsoft «ASP Template Caching» указывается, что для этой папки группе IIS_WPG требуются только разрешения Read, Write и Delete, но в действительности группе предоставляется Full Control. Неверная информация приводится и в статье Microsoft «AspDiskTemplateCacheDirectory», в которой говорится: «Как правило, идентификаторы процессов, выполняющих Asp.dll, — учетные записи IWAM_USER и System». Данное утверждение явно относится к IIS 5.0, но не к IIS 6.0, так как IIS 6.0 по умолчанию использует запись Network Service.

    К счастью, размещение компилируемых шаблонов настраивается по сайту, папке и виртуальному каталогу. В результате можно построить раздельные папки кэша шаблонов ASP, назначив им такие разрешения NTFS, что ни одно другое приложение, работающее на сайте (за исключением имеющих разрешения Administrator или System), не сможет производить чтение или запись в папке кэша шаблонов. Местоположение определяется параметром AspDiskTemplateCacheDirectory в метабазе. Можно создать этот параметр метабазы с помощью Metabase Explorer или Adsutil, а затем связать его с уникальной папкой для защищенного приложения. Разрешения Full Control следует предоставить администраторам и уникальному экземпляру процесса, назначенному защищенному пулу приложений.

    При подготовке программ к изоляции в ASP.NET необходимо корректно настроить разрешения для временных файлов ASP.NET. Группе IIS_WPG предоставляются разрешения Full Control в папке \%systemroot%Microsoft.NET Frame workv1.1.4322Temporary ASP.NET Files. К счастью, указать местонахождение временных файлов ASP.NET можно для каждого приложения отдельно через элемент файла web.config, как описано в статье Microsoft «ASP.NET Settings Schema». Таким образом обеспечивается должный уровень изоляции и защиты папки.

    Безусловно, специалистам, не использующим ASP или ASP.NET, необходимо выяснить область полномочий группы IIS_WPG в языке сценариев или приложении, и принять соответствующие меры. Если возникает ситуация, когда для корректного функционирования приложения необходимо предоставить группе IIS_WPG разрешения в определенном каталоге и такой каталог единственный на всем сервере, следует убедиться, что другие приложения на сервере не могут прочитать и изменить данные защищенного приложения в этом каталоге. Как уже отмечалось, в число таких каталогов входят кэши временных файлов, а также общие базы данных, файлы настройки, общие двоичные файлы и т. д. Детали целиком определяются конкретными обстоятельствами.

    С помощью утилиты cacls.exe можно вывести разрешения в текстовый файл для последующего анализа. Ниже приведен пример для стандартной установки IIS.

    cacls C:inetpubwwwroot* /T > output.txt

    Управление анонимным доступом

    Наконец, необходимо создать уникальную учетную запись анонимного пользователя для защищенного Web-узла. Этому пользователю не нужны особые разрешения, так как все необходимые права имеются у стандартной учетной записи пользователя. Здесь важно выбрать очень надежный пароль и не следует использовать IUSR в качестве имени учетной записи — в противном случае IIS может перепутать стандартную учетную запись IUSR с учетной записью, созданной администратором.

    При назначении разрешений NTFS следует помнить, что для защищенного контента нельзя использовать такие группы, как Users, Authenticated Users и Everyone, если только анонимным пользователям явно не запрещено обращаться к другим Web-узлам во всем каталоге с контентом.

    Другие технологии и факторы

    Задача изоляции приложений часто не ограничивается отдельным сервером IIS и распространяется на другие серверы предприятия. Детали способа доступа к сетевым ресурсам, контекст безопасности, используемые службы и механизмы аутентификации играют определенную роль в организации доступа приложения к базе данных, файл-серверу и другим сетевым устройствам. Эти вопросы выходят за рамки данной статьи, но читатели могут ознакомиться с разделами COM+ в статье «What Are COM+ Partitions» и ограниченным делегированием в статье «Kerberos Protocol Transition and Constrained Delegation» на сайте Microsoft. Кроме того, можно прочитать документ «Configuring Application Isolation on Windows Server 2003 and Internet Information Services (IIS) 6.0».

    Методичный подход — залог успеха

    Разместить приложение на IIS-сервере, максимально изолировав его от других приложений на том же сервере, — нелегкая задача. IIS 5.0 не подходит для этой цели из-за неупорядоченности экземпляров процессов и управляющих ими механизмов. IIS 6.0 — гораздо более удобная платформа. Изолировать приложения здесь проще благодаря контролю над экземпляром процесса пулов приложений и управлению разрешениями NTFS. Для изоляции и защиты любых каталогов, использующих группу IIS_WPG, требуется точность, и администратору необходимо аккуратно назначать разрешения NTFS. Однако, придерживаясь методичного подхода, можно достичь высокой степени изоляции.

    Специалист по IIS 7.0 и Web-службам в Microsoft, редактор журнала Windows IT Pro. brett@iisanswers.com

    Поделитесь материалом с коллегами и друзьями

    Реферат: работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0

    МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

    ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

    ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

    «ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

    ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

    КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

    Построение веб-приложения на основе ASP.NET и архитектуры сервера IIS 7.0

    Выполнил: студент 367 гр.

    Введение

    В настоящее время сложно переоценить роль интернета. Это одна из наиболее динамично развивающихся отраслей, даже в условиях кризиса.

    А что такое интернет без веб страниц и, соответственно, веб серверов?

    Сейчас на рынке можно достаточно большое количество самых разных веб серверов. Один из наиболее распространенных – это Internet Information Server корпорации Microsoft. Учитывая последние тенденции к комплексным решениям Microsoft выпустила IIS 7.0, дающий разработчикам и администраторам новые возможности при создании и управлении сайтами.

    В своей работе я ознакомился с новыми возможностями и применил их на практике.

    Изучив возможности нового веб сервера, создать свой аутентификационный модуль для веб приложения.

    Задачи:

    1. Изучить новые возможности IIS 7.0

    2. Познакомится с ASP.NET

    3. Написать модуль аутентификации

    Теоретическая часть

    Безопасность в сети необходима, особенно если дело касается денег. Злоумышленники прибегнут к всевозможным ухищрениям лишь бы добраться до номера вашего банковского счета, логина и пароля в интернет-магазине. Данный проект написан на C# с применением технологии ASP.NET неслучайно. Существует множество готовых решений и предусмотренных классов для обеспечения безопасности соединения. Microsoft предлагает комплексные решения для многих задач. Продукты этой фирмы используются почти всеми, как в корпоративной сети, так и в обычной жизни. Интересующая нас задача — это создание и сопровождение полноценных защищенных веб приложений, таких как интернет магазин например.

    Для создания безопасного веб-приложения необходимо полное понимание слабых мест в системе безопасности. Также необходимо ознакомиться с функциями обеспечения безопасности Windows, .NET Framework и ASP.NET. И, наконец, очень важно понимать способы использования этих функций безопасности для борьбы с угрозами.

    Давайте рассмотрим поближе систему безопасности ASP.NET

    Чтобы обеспечить безопасность веб-приложений, ASP.NET используется совместно с Microsoft .NET Framework и службами Microsoft Internet Information Services (IIS). Для создания безопасного приложения ASP.NET следует выполнить две основные функции:

    · Проверка подлинности (Приложение получает от пользователя учетные данные (различные формы идентификации, такие как имя и пароль) и сравнивает их с данными авторитетного источника.)

    · Авторизация (Ограничивает право доступа, предоставляя определенные разрешения или отказывая в них удостоверенной личности)

    ASP.NET в сочетании со службами Microsoft Internet Information Services (IIS) может выполнять проверку подлинности учетных данных пользователя, например имен и паролей, используя любой из перечисленных ниже методов проверки подлинности:

    · Windows: стандартная, шифрованная или встроенная проверка подлинности Windows (NTLM или Kerberos).

    · Проверка подлинности в формах, в которых разработчик создает страницу входа и управляет проверкой подлинности в приложении.

    · Проверка подлинности с помощью сертификатов клиента.

    Рассмотрим Архитектуру безопасности ASP.NET

    Рис.1 Архитектура безопасности ASP.NET

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

    Во время выполнения приложение ASP.NET может использовать встроенные средства безопасности ASP.NET. Кроме того, в приложении ASP.NET могут использоваться средства безопасности платформы .NET Framework.

    Два стандартных стандартных сценария обеспечения безопасности: олицетворение(проверка подлинности Windows) и проверки подлинности с помощью форм с использованием файлов «cookies».

    Олицетворение

    Рис.2 Олицетворение. На рисунке показана следующая последовательность событий:

    1. Запрос поступает в службы IIS от клиента сети.

    2. Службы IIS проверяют подлинность клиента, используя стандартную, шифрованную или встроенную безопасность Windows (NTLM или Kerberos).

    3. Если клиент проходит проверку подлинности, службы IIS передают удостоверенный запрос в ASP.NET.

    4. Приложение ASP.NET олицетворяет клиент, выполняющий запрос, используя лексему доступа, переданную из IIS, и использует разрешения NTFS-файла для предоставления доступа к ресурсам. Приложение ASP.NET должно только проверить, что в файле конфигурации ASP.NET для олицетворения задано значение true ; код безопасности для ASP.NET писать не требуется. Если олицетворение не включено, приложение запускается с удостоверением процесса ASP.NET. Для Microsoft Windows 2000 Server и Windows XP Professional удостоверением по умолчанию является локальная учетная запись с именем ASPNET, которая создается автоматически при установке ASP.NET. Для Microsoft Windows Server 2003 удостоверением по умолчанию является удостоверение пула приложений для приложения IIS (по умолчанию учетная запись NETWORK SERVICE).

    5. Если доступ разрешен, приложение ASP.NET возвращает запрошенный ресурс через IIS.

    Проверка подлинности с помощью форм

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

    Рис.3 Проверка подлинности форм. На рисунке показана следующая последовательность событий:

    1. Пользователь создает запрос на защищенный ресурс.

    2. Службы IIS получают запрос, и так как IIS разрешают анонимный доступ, они не выполняют никакой проверки подлинности пользователя и передают запрос приложению ASP.NET.

    3. Так как ASP.NET использует режим поверки подлинности с помощью форм, приложение ASP.NET проверяет билет проверки подлинности на основе форм для запроса (отдельный файл «cookie»). Если к запросу не приложен билет проверки подлинности, ASP.NET перенаправляет запрос на страницу входа в систему, указанную в файле конфигурации приложения. На странице входа в систему пользователь вводит необходимые учетные данные, обычно имя и пароль. Код приложения проверяет учетные данные, чтобы подтвердить их подлинность. Если учетные данные проходят проверке подлинности, код приложения вкладывает билет проверки подлинности в ответ, который представляет учетные данные пользователя. (Пароль не включается). Если проверка подлинности не пройдена, ответ возвращается с сообщением об отказе в доступе, либо форма входа в систему представляется повторно.Выпущенный билет проверки подлинности включается в следующий запрос к приложению ASP.NET. ASP.NET проверяет допустимость использования билетом проверки подлинности сообщения (MAC).

    4. Если пользователь проходит проверку подлинности, ASP.NET проверяет подлинность и может разрешить доступ к изначально запрошенному ресурсу, перенаправить запрос на другую страницу или на пользовательский модуль проверки подлинности, где учетные данные тестируются для разрешения доступа к защищенным ресурсам. Если авторизация завершается неуспешно, ASP.NET перенаправляет пользователя на страницу входа в систему.

    5. Если пользователь прошел авторизацию, доступ к защищенному ресурсу разрешается или, перед тем как разрешить доступ, приложение, в зависимости от собственной схемы, также может потребовать дополнительную проверку учетных данных.

    IIS 7.0 Особенности

    В основе выпуска IIS 7.0 лежит полностью модульный веб-сервер, включающий более 40 компонентов, которые можно объединять в компактные веб-серверы, оптимизированные для необходимой роли в топологии приложения. Эти компоненты создаются на основе нового слоя расширяемости, что позволяет разработчикам расширять или замещать практически любую функцию сервера в машинном коде или с помощью Microsoft® .NET Framework. IIS 7.0 предлагает расширяемость компонентов этапа выполнения, управления и рабочих компонентов, облегчая создание комплексных решений в соответствии с конкретными потребностями. На базе основной платформы IIS 7.0 берется за решение многих проблем, связанных с управляемостью и эксплуатацией сервера. Он обладает принципиально новой системой настройки, обеспечивающей полностью делегированное управление узлами и, в конечном итоге, делающей реальностью развертывание веб-приложений с использованием xcopy. Новые интерфейсы API для целей управления и диагностические компоненты делают процедуры развертывания, администрирования и устранения неполадок сервера значительно проще и удобнее, чем когда-либо прежде.


    IIS 7.0 разбивает веб-сервер на небольшое ядро сервера и более чем 40 модулей компонентов, подключаемых к этому ядру. Эти модули — такие, как StaticFileModule, который позволяет загружать статическое веб-содержимое, или WindowsAuthModule, поддерживающий встроенную проверку подлинности NTLM, — можно устанавливать на сервере независимо, чтобы обеспечить именно те функциональные возможности, которые необходимы.

    Эти модули можно в любое время полностью удалить с сервера или намеренно отключить на время работы конкретного приложения, которому они не требуются. Такая возможность позволяет администраторам сервера быстро развертывать серверы минимальной конфигурации со значительным уменьшением мест, доступных для атак, и существенным увеличением производительности за счет выполнения только необходимого кода. Архитектура, построенная из независимых компонентов, является важнейшим свойством IIS 7.0, ведущим к снижению рисков нарушения безопасности и минимизации необходимости вносить исправления. Она делает возможными специализированные развертывания сервера, для которых объединяются выбранные компоненты IIS и специальные составляющие, оптимизированные для конкретной роли сервера в топологии приложения, например, обратных прокси и кэширующих серверов, серверов балансировки нагрузки протокола HTTP или SSL и серверов безопасности Sentinel.

    Все компоненты сервера, поставляемые с IIS 7.0, созданы на основе новых общедоступных интерфейсов API расширяемости. У разработчика имеется возможность заместить любой из существующих компонентов сервера своим собственным или создать новый модуль для добавления его к набору компонентов IIS 7.0. Новые интерфейсы API расширяемости являются фундаментальным усовершенствованием предыдущей модели расширяемости ISAPI и позволяют расширить возможности сервера за счет большей гибкости и простоты использования. Практически каждая отдельная характеристика сервера, начиная с ядра сервера, и вплоть до его конфигурации, управления и диагностики, обеспечивает расширяемость, что позволяет расширять сервер и формировать его в соответствии с конкретными потребностями.

    Упрощенное развертывание и настройка

    Централизованное хранилище конфигураций предыдущих версий IIS, известное как метабаза, ушло в прошлое. Для IIS 7.0 характерна новая система делегированной настройки, основанная на иерархии распределенных файлов настройки в формате XML. Данная иерархия обобщена в глобальном файле applicationHost.config, в котором содержатся значения по умолчанию для настройки уровня сервера, и распределенных файлах web.config, находящихся в структуре каталогов приложения. Это те же самые файлы, которые используются инфраструктурой приложения ASP.NET для хранения параметров в переносимом виде. Это позволяет хранить одновременно конфигурации IIS и ASP.NET, используя четкие и жестко структурированные директивы XML. Вот один пример:

    В прошлом для того, чтобы приложение IIS работало надлежащим образом, требовалось точно настроить параметры приложения в хранилище метабазы на уровне компьютера. В случае распределенных файлов web.config приложения инкапсулируют требуемую настройку сервера в структуру своих каталогов. Это существенно упрощает развертывание, позволяя независимые приложения просто копировать в каталог приложения на целевом сервере и незамедлительно запускать подготовленные приложения с требуемыми параметрами.

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

    В полном соответствии основной идее IIS 7.0 система настройки является полностью расширяемой. Новые модули могут добавлять собственные схемы настройки, позволяя приложениям настраивать свои компоненты наряду с настройкой IIS и ASP.NET:

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

    IIS 7.0 продолжает поддерживать существующий код настройки, использующий для записи в традиционную метабазу интерфейсы API объекта ABO (Admin Base Object) или сценарии, использующие интерфейсы высокого уровня ADSI (Active Directory® Service Interfaces) и объекты WMI (Windows Management Instrumentation) для настройки IIS. Это достигается посредством предоставления слоя совместимости, который эмулирует интерфейсы API объектов ABO, являющиеся основой для всех других традиционных интерфейсов API настройки, позволяя таким сценариям читать и изменять настройку тем же способом, как они делали это в предыдущих версиях IIS. В то время как новый формат настройки с использованием структурированного XML облегчает работу с конфигурацией в привычном текстовом редакторе, IIS предоставляет администраторам также узел с инструментами управления и интерфейсы API, облегчающие управление сервером и делающие возможной автоматизированную настройку и развертывание.

    .NET Framework и создание сценариев

    Кроме администрирования сервера вручную с помощью IIS Manager или инструмента командной строки appcmd.exe IIS 7.0 предоставляет множество возможностей программного администрирования. Во-первых, можно использовать интерфейс API Microsoft.Web.Administration для управления сервером из приложений .NET. Или использовать новый интерфейс API COM для непосредственного управления системой настройки IIS, либо получить к ней доступ из среды создания сценариев, например ASP или Windows® Script Host (WSH). Существует также новый поставщик WMI и поддержка традиционных поставщиков WMI и ADSI посредством слоя совместимости метабазы.

    Microsoft.Web.Administration, новый интерфейс API администрирования .NET, облегчает приложениям управляемого кода обеспечивать программную поддержку узлов и приложений IIS, получать доступ к важной информации о состоянии и диагностическим данным и изменять настройку сервера. Способность приложений на основе .NET Framework беспрепятственно получать доступ к информации о настройке IIS и данным о состоянии открывает необъятный простор для написания приложений настройки с использованием .NET и управляющих приложений или даже выполнения задач управления непосредственно из страниц ASP.NET.

    Создание компонентов веб-сервера

    IIS 7.0 дает возможность сформировать сервер в соответствии с конкретными потребностями, позволяя добавлять или заменять в сервере любой компонент для обеспечения требуемого набора функций. В основе этой возможности лежит совершенно новый интерфейс расширяемости веб-сервера, на основе которого создаются все существующие компоненты HTTP IIS 7.0. Этот интерфейс API является открытым, что означает возможность реализации любого из компонентов, поставляемых с IIS 7.0. Для IIS это самое важное и фундаментальное усовершенствование по сравнению с предыдущей ограниченной моделью расширяемости ISAPI.

    Новый интерфейс расширяемости представляет собой набор интуитивных классов C++, определяющих объектную модель и дающих возможность модулю предоставлять службы обработки запросов на IIS. Эти классы определяются в заголовочном файле в Windows Vista SDK.

    В сравнении с ISAPI эти интерфейсы API являются как более мощными, так и намного более простыми в использовании. Как такое возможно? Во-первых, для нового интерфейса API характерна хорошо инкапсулированная модель с безопасными типами. Разработка существенно облегчается благодаря использованию новой объектной модели сервера, предоставляющей специализированные интерфейсы для всех основных объектов сервера и задач. К ним относятся:

    · Проверка запроса с помощью класса IHttpRequest

    · Управление откликом с помощью класса IHttpResponse

    · Использование полезных функций служебных программ класса IHttpServer

    · Обеспечение проверки подлинности с помощью класса IHttpUser

    · Получение доступа к разделу пользовательской настройки вашего модуля с помощью интерфейсов API настройки

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

    Разработчики получат преимущество также благодаря усовершенствованным шаблонам для управления памятью и состоянием. Большинство интерфейсов API сервера IIS 7.0 используют для возвращаемых данных память, управляемую сервером, вместо запроса на выделение буферов и управления ими, как это делает ISAPI и большинство существующих интерфейсов API в Win32®. В прошлом это был один из наиболее подверженных ошибкам и утомительных этапов разработки ISAPI. Новый интерфейс API упрощает также многие сложные задачи обработки запросов, например, буферизацию отклика, проверку подлинности и подготовку данных отклика для клиента

    Интеграция ASP.NET

    В составе сервера IIS 7.0 ASP.NET приходит в двух версиях: Режим Classic и режим Integrated Режим Classic работает точно так же, как он работал в предыдущих версиях IIS. Режим Integrated, являющийся платформой по умолчанию, использует совершенно новый обработчик для обеспечения интеграции высочайшего уровня с веб-сервером IIS. В режиме Integrated интерфейсы API ASP.NET можно использовать для разработки модулей IIS 7.0, которые напрямую интегрируются с веб-сервером и в состоянии предоставлять практически все возможные службы благодаря лежащему в основе интерфейсу API на C++,.

    По существу, это оптимальный вариант — знакомые интерфейсы и удобные службы приложений .NET Framework и ASP.NET 2.0, такие, как управление членством и ролями, плюс неограниченная возможность расширения сервера, ранее доступная только составляющим ISAPI, написанным на C.

    В добавление к возможности написания новых модулей ASP.NET, основанной на особых преимуществах режима Integrated, многие унаследованные модули ASP.NET можно сделать гораздо более мощными простым изменением нескольких параметров настройки в файле web.config.

    Рис 4. Жизненный цикл ASP.NET

    Для разработчиков ASP.NET преимущества интегрированного конвейера заключаются в следующем:

    • Интегрированный конвейер может вызывать все события, объявленные в объекте HttpApplication, что позволяет существующим HTTP-модулям ASP.NET работать в интегрированном режиме IIS 7.0.
    • И модули машинного кода, и модули управляемого кода можно настраивать на уровне веб-сервера, веб-узла и веб-приложения. Это относится и к встроенным модулям управляемого кода ASP.NET для управления состоянием сеанса, проверкой подлинности форм, профилями и ролями. Более того, поддержку модулей управляемого кода можно включить или отключить для всех запросов, независимо от того, предназначен ли запрос для ресурса ASP.NET, например ASPX-файла.
    • Модули управляемого кода можно вызывать на любом этапе конвейера. Это можно сделать до обработки запроса на сервере, после обработки на сервере или в любой момент во время обработки.
    • Регистрация, включение и отключение модулей выполняется в файле Web.config приложения.

    Модули управляемого кода в службах IIS 7.0

    • FormsAuthenticationModule
    • ProfileModule
    • RoleManagerModule
    • SessionStateModule

    Разработка настраиваемых модулей управляемого кода

    Жизненный цикл приложения ASP.NET можно расширить с помощью модулей, в которых реализован интерфейс IHttpModule. Модули, в которых реализован интерфейс IHttpModule, являются модулями управляемого кода. Интегрированный конвейер ASP.NET и IIS 7.0 также можно расширить с помощью модулей машинного кода, которые в данном разделе не рассматриваются. Модуль управляемого кода можно задать как файл класса в папке App_Code приложения. Также можно создать модуль как проект библиотеки классов, скомпилировать его и добавить в папку Bin приложения. После создания настраиваемого модуля его необходимо зарегистрировать с помощью IIS 7.0. Для управления модулями управляемого кода IIS 7.0 можно воспользоваться одним из описанных ниже методов. Например, чтобы зарегистрировать модуль управляемого кода только для одного приложения, можно изменить файл Web.config этого приложения. Если модуль находится в папке App_Code или Bin и зарегистрирован в файле Web.config приложения, этот модуль вызывается только для этого приложения. Чтобы зарегистрировать модуль Web.config приложения, необходимо изменить элемент modules в разделе system.webServer . Изменения, внесенные с помощью IIS Manager или средства Appcmd.exe, вносятся в файл Web.config приложения.

    Модули управляемого кода также можно зарегистрировать в элементе modules хранилища конфигурации IIS 7.0 (файл ApplicationHost.config). Модули, зарегистрированные в файле ApplicationHost.config, обладают глобальной областью действия, поскольку они зарегистрированы для всех веб-приложений, размещенных с помощью служб IIS 7.0. Модули машинного кода, заданные в элементе globalModules файла ApplicationHost.config, также обладают глобальной областью действия. Если глобальный модуль в веб-приложении не используется, его можно отключить.

    Практическая часть

    Мною был реализован процесс аутентификации и проверки подлинности пользователей входящих на сайт. В него входят: страница, сценарий которой сверяет введенные пользователем данные с хранящимися в базе пользователей и формирует билет аутентификации, хранимый в cookies пользователя, и пользовательский модуль IIS, который проверяет наличие правильного билета и в последствие может быть расширен в соответствии с логикой приложения. Например, проверка роли пользователя и запрет на обращение к определенным страницам или сокрытие управляющих конструкций, при недостаточных правах.

    При правильной настройке сервера действия, прописанные в модуле будут вызываться всякий раз при обращении пользователя к любому ресурсу сервера. Хоть система безопасности отклоняет «подозрительные» запросы к ресурсам, можно в написать свой модуль или обработчик, анализирующий и отклоняющий опасные запросы и попытки атак.

    Модуль реализован с применением стандартного класса IHttpModule.

    public class userAuth : IHttpModule

    public void Init(HttpApplication app)

    app.AuthenticateRequest += new EventHandler(this.Authorize);

    При каждом обращении к странице возникает событие AuthenticateRequest, на которое модуль реагирует обработчиком события Authorize

    public void Authorize(Object source, EventArgs e)

    HttpApplication application = (HttpApplication)source;

    LAV_ СИТспец_маг2014-15 / Модуль1_2013-14 / Web-приложения ASP_NET

    Разработка Web-приложений ASP .NET с использованием Visual Studio .NET

    Принципы работы и структура Web-приложений на основе ASP.NET

    Основы работы в Visial Studio .NET

    Основы Web-программирования с использованием ASP.NET

    Принципы разработки пользовательского интерфейса интернет-приложения

    Использование Master Page и навигация при построении интернет-приложений

    Навигация по Web-приложению

    Использование тем при оформлении Web-приложения

    Использование кэширования в Web-приложениях

    Использование баз данных в приложениях ASP.NET

    Принципы работы и структура Web-приложений на основе ASP.NET

    Рассматривается архитектура современных Web-приложений, взаимодействие клиентской и серверной частей таких приложений, принципы их организации в среде ASP.NET

    Цель лекции: познакомиться с архитектурой и особенностями организации Web-приложений, особенностями архитектуры ASP.NET и .NET Framework, принципами взаимодействия клиента и сервера при выполнении Web-приложения на основе ASP.NET.

    Web-приложения представляют собой особый тип программ, построенных по архитектуре «клиент-сервер». Особенность их заключается в том, что само Web-приложение находится и выполняется на сервере — клиент при этом получает только результаты работы. Работа приложения основывается на получении запросов от пользователя (клиента), их обработке и выдачи результата. Передача запросов и результатов их обработки происходит через Интернет ( рис.1.1).

    Рис. 1.1. Архитектура Web-приложения

    Отображением результатов запросов, а также приемом данных от клиента и их передачей на сервер обычно занимается специальное приложение — браузер (Internet Expolrer, Mozilla, Opera и т. д.). Как известно, одной из функций браузера является отображение данных, полученных из Интернета, в виде страницы, описанной на языке HTML, следовательно, результат, передаваемый сервером клиенту, должен быть представлен на этом языке.

    На стороне сервера Web-приложение выполняется специальным программным обеспечением (Web-сервером), который и принимает запросы клиентов, обрабатывает их, формирует ответ в виде страницы, описанной на языке HTML, и передает его клиенту. Одним из таких Web-серверов является Internet Information Services (IIS) компании Microsoft. Это единственный Web-сервер, который способен выполнять Web-приложения, созданные с использованием технологии ASP.NET.

    В процессе обработки запроса пользователя Web-приложение компонует ответ на основе исполнения программного кода, работающего на стороне сервера, Web-формы, страницы HTML, другого содержимого, включая графические файлы. В результате, как уже было сказано, формируется HTML-страница, которая и отправляется клиенту. Получается, что результат работы Web-приложения идентичен результату запроса к традиционному Web-сайту, однако, в отличие от него, Web-приложение генерирует HTML-код в зависимости от запроса пользователя, а не просто передает его клиенту в том виде, в котором этот код хранится в файле на стороне сервера. То есть Web-приложение динамически формирует ответ с помощью исполняемого кода — так называемой исполняемой части.

    За счет наличия исполняемой части, Web-приложения способны выполнять практически те же операции, что и обычные Windows-приложения, с тем лишь ограничением, что код исполняется на сервере, в качестве интерфейса системы выступает браузер, а в качестве среды, посредством которой происходит обмен данными, — Интернет. К наиболее типичным операциям, выполняемым Web-приложениями, относятся:

    прием данных от пользователя и сохранение их на сервере;

    выполнение различных действий по запросу пользователя: извлечение данных из базы данных (БД), добавление, удаление, изменение данных в БД, проведение сложных вычислений;

    аутентифицирование пользователя и отображение интерфейса системы, соответствующего данному пользователю;

    отображение постоянно изменяющейся оперативной информации и т. д.

    Краткое описание архитектуры ASP.NET и .NET Framework

    ASP.NET — это платформа для создания Web-приложений и Web-сервисов, работающих под управлением IIS. Сегодня существуют другие технологии, позволяющие создавать Web-приложения. К ним относятся прежде всего, очень популярные сегодня языки PHP и PERL, более старая и менее популярная технология CGI и т. д. Однако ASP.NET отличается от них высокой степенью интеграции с серверными продуктами, а также с инструментами Microsoft для разработки доступа к данным и обеспечения безопасности. Кроме того, ASP.NET позволяет разрабатывать Web- и Windows-приложения, используя очень похожие технологические цепочки, одинаковые языки программирования, технологии доступа к данным и т. д. Более того, базовые языки программирования, с помощью которых сегодня возможна разработка Web-приложений, являются полностью объектно-ориентированными, что делает разработку исполнимой части, а также ее модификацию, обслуживание, отладку и повторное использование гораздо более простым занятием, чем в других технологиях. Существует достаточно большой перечень сильных сторон использования ASP.NET для создания сложных Web-приложений. Целью данного курса не является описание всех сильных и слабых сторон этой платформы.

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

    Важным моментом в понимании архитектуры ASP.NET является тот факт, что она является частью инфраструктуры .NET Framework. Более подробно об архитектуре и принципах работы .NET Framework можно узнать в [2]. Так как эта тема является слишком объемной и выходит за рамки данного курса, ограничимся лишь кратким описанием инфраструктуры .NET Framework.

    Архитектура .NET Framework

    Как утверждает корпорация Microsoft, до 80% средств, направленных на исследования и разработки, тратится на платформу .NET и связанные с ней технологии. Результаты такой политики на сегодняшний день выглядят впечатляюще. Так, область охвата платформы .NET просто огромна. Платформа состоит из четырех групп программных продуктов:

    набор языков, куда входят С# и Visual Basic .NET; набор инструментальных средств разработки, в том числе Visual Studio .NET; обширная библиотека классов для построения Web-служб и приложений, работающих в Windows и в Интернете; а также среда выполнения программ CLR (Common Language Runtime — общеязыковая среда выполнения), в которой выполняются объекты, построенные на этой платформе;

    набор серверов .NET Enterprise Servers, ранее известных под именами SQL Server 2000, Exchange 2000, BizTalk 2000 и др., которые предоставляют специализированные функциональные возможности для обращения к реляционным базам данных, использования электронной почты, оказания коммерческих услуг «бизнес-бизнес» (В2В) и т. д.;

    богатый выбор коммерческих Web-служб, называемых .Net My Services. За умеренную плату разработчики могут пользоваться этими службами при построении приложений, требующих идентификации личности пользователя и других данных;

    новые некомпьютерные устройства, поддерживающие средства .NET, — от сотовых телефонов до игровых приставок.

    Microsoft .NET поддерживает не только языковую независимость, но и языковую интеграцию. Это означает, что разработчик может наследовать от классов, обрабатывать исключения и использовать преимущества полиморфизма при одновременной работе с несколькими языками. Платформа .NET Framework предоставляет такую возможность с помощью спецификации CTS (Common Type System — общая система типов), которая полностью описывает все типы данных, поддерживаемые средой выполнения, определяет, как одни типы данных могут взаимодействовать с другими и как они будут представлены в формате метаданных .NET. Например, в .NET любая сущность является объектом какого-нибудь класса, производного от корневого класса System.Object. Спецификация CTS поддерживает такие общие понятия, как классы, делегаты (с поддержкой обратных вызовов), ссылочные и размерные типы.

    Важно понимать, что не во всех языках программирования .NET обязательно должны поддерживаться все типы данных, которые определены в CTS. Спецификация CLS (Common Language Specification — общая языковая спецификация) устанавливает основные правила, определяющие законы, которым должны следовать все языки: ключевые слова, типы, примитивные типы, перегрузки методов и т. п. Спецификация CLS определяет минимальные требования, предъявляемые к языку платформы .NET. Компиляторы, удовлетворяющие этой спецификации, создают объекты, способные взаимодействовать друг с другом. Любой язык, соответствующий требованиям CLS, может использовать все возможности библиотеки FCL (Framework Class Library — библиотека классов платформы). CLS позволяет и разработчикам, и поставщикам, и производителям программного обеспечения не выходить за пределы общего набора правил для языков, компиляторов и типов данных.

    Платформа .NET Framework является надстройкой над операционной системой, в качестве которой может выступать любая версия Windows 1) . На сегодняшний день платформа .NET Framework включает в себя:

    четыре официальных языка: С#, VB.NET, Managed C++ (управляемый C++) и JScript .NET;

    объектно-ориентированную среду CLR (Common Language Runtime), совместно используемую этими языками для создания приложений под Windows и для Internet;

    ряд связанных между собой библиотек классов под общим именем FCL (Framework Class Library).

    Отношения архитектурных компонентов платформы .NET Framework с концептуальной точки зрения представлены на рис.1.2.

    Рис. 1.2. Архитектура .NET Framework

    Самым важным компонентом платформы .NET Framework является CLR (Common Language Runtime), предоставляющая среду, в которой выполняются программы. Главная ее роль заключается в том, чтобы обнаруживать и загружать типы .NET и производить управление ими в соответствии с полученными командами. CLR включает в себя виртуальную машину, во многих отношениях аналогичную виртуальной машине Java. На верхнем уровне среда активизирует объекты, производит проверку безопасности, размещает объекты в памяти, выполняет их, а также запускает сборщик мусора.

    Под сборкой мусора понимается освобождение памяти, занятой объектами, которые стали бесполезными и не используются в дальнейшей работе приложения. В ряде языков программирования (например, C/C++) память освобождает сам программист, в явной форме отдавая команды как на создание, так и на удаление объекта. В этом есть своя логика — «я тебя породил, я тебя и убью». Однако в CLR задача сборки мусора (и другие вопросы, связанные с использованием памяти) решается в нужное время и в нужном месте исполнительной средой, ответственной за выполнение вычислений.

    На на рис.1.2. над уровнем CLR находится набор базовых классов платформы, над ним расположены слой классов данных и XML, а также слой классов для создания Web-служб (Web Services), Web- и Windows-приложений (Web Forms и Windows Forms). Собранные воедино, эти классы известны под общим именем FCL (Framework Class Library). Это одна из самых больших библиотек классов в истории программирования. Она открывает доступ к системным функциям, включая и те, что прежде были доступны только через API Windows, а также к прикладным функциям для Web-разработки (ASP.NET), доступа к данным (ADO.NET), обеспечения безопасности и удаленного управления. Имея в своем составе более 4000 классов, библиотека FCL способствует быстрой разработке настольных, клиент-серверных и других приложений и Web-служб.

    Набор базовых классов платформы — нижний уровень FCL — не только прячет обычные низкоуровневые операции, такие как файловый ввод/вывод, обработка графики и взаимодействие с оборудованием компьютера, но и обеспечивает поддержку большого количества служб, используемых в современных приложениях (управление безопасностью, поддержка сетевой связи, управление вычислительными потоками, работа с отражениями и коллекциями и т. д.).

    Над этим уровнем находится уровень классов, которые расширяют базовые классы с целью обеспечения управления данными и XML. Классы данных позволяют реализовать управление информацией, хранящейся в серверных базах данных. В число этих классов входят классы SQL (Structured Query Language, язык структурированных запросов), дающие программисту возможность обращаться к долговременным хранилищам данных через стандартный интерфейс SQL. Кроме того, набор классов, называемый ADO.NET, позволяет оперировать постоянными данными. Платформа .NET Framework поддерживает также целый ряд классов, позволяющих манипулировать XML-данными и выполнять поиск и преобразования XML.

    Базовые классы, классы данных и XML расширяются классами, предназначенными для построения приложений на основе трех различных технологий: Web Services (Web-службы), Web Forms (Web-формы) и Windows Forms (Windows-формы). Web-службы включают в себя ряд классов, поддерживающих разработку облегченных распределяемых компонентов, которые могут работать даже с брандмауэрами и программами трансляции сетевых адресов (NAT). Поскольку Web-службы применяют в качестве базовых протоколов связи стандартные протоколы HTTP и SOAP, эти компоненты поддерживают в киберпространстве подход «Plug & Play».

    Инструментальные средства Web Forms и Windows Forms позволяют применять технику RAD (Rapid Application Development — быстрая разработка приложений) для построения Web- и Windows-приложений. Эта техника сводится к перетаскиванию элементов управления с панели инструментов на форму, двойному щелчку по элементу и написанию кода, который обрабатывает события, связанные с этим элементом.

    Компиляция и язык MSIL

    .NET-приложения исполняются иначе, чем традиционные Windows-приложения. Такие программы компилируются фактически в два этапа. На первом этапе исходный код компилируется во время построения проекта и вместо исполняемого файла с машинными кодами получается сборка 2) (assembly), содержащая команды промежуточного языка MSIL (Microsoft Intermediate Languageпромежуточный язык Microsoft). Код IL сохраняется в файле на диске. При этом файлы MSIL (сокращенно IL), генерируемые компилятором, например, С#, идентичны IL-файлам, генерируемым компиляторами с других языков .NET. В этом смысле платформа остается в неведении относительно языка. Самой важной характеристикой среды CLR является то, что она общая; одна среда выполняет как программы, написанные на С#, так и программы на языке VB.NET.

    Второй этап компиляции наступает непосредственно перед фактическим выполнением страницы. На этом этапе CLR транслирует промежуточный код IL в низкоуровневый собственный машинный код, выполняемый процессором. Процесс происходит следующим образом: при выполнении .NET-программы системы CLR активизирует JIT-компилятор, который затем превращает MSIL во внутренний код процессора. Этот этап известен как оперативная компиляция «точно к нужному моменту» (Just-In-Time) или JIT-компиляция (JIT’ing), и он проходит одинаково для всех приложений .NET (включая, например, приложения Windows). При исполнении программы CLR берет на себя управление памятью, контроль типов и решает за приложение ряд других задач. На рис.1.3. показан этот двухэтапный процесс компиляции.

    Рис. 1.3. Схема компиляции .NET-приложения

    Стандартный JIT-компилятор работает по запросу. Когда вызывается тот или иной метод, JIT-компилятор анализирует IL-код и производит высокоэффективный машинный код, выполняемый очень быстро. JIT-компилятор достаточно интеллектуален, чтобы распознать, был ли код уже скомпилирован, поэтому во время выполнения программы компиляция происходит лишь при необходимости. По ходу своего выполнения .NET-программа работает все быстрее и быстрее, так как повторно используется уже скомпилированный код.

    Спецификация CLS подразумевает, что все языки платформы .NET генерируют очень похожий IL-код. Кроме того, при компилировании программы в дополнение к MSIL формируется еще один компонент — метаданные. Они описывают данные, используемые программой, и это позволяет коду взаимодействовать с другим кодом. В результате объекты, созданные на одном языке, доступны и могут наследоваться на другом. То есть можно создать базовый класс на языке VB.NET, а производный от него класс — на языке С#.

    В целом при написании приложения создается так называемый управляемый код (managed code), который выполняется под контролем среды исполнения CLR-приложения, не зависящей от языка. Поскольку приложение запускается под контролем CLR, управляемый код должен соответствовать определенным требованиям (т. е. компилятор должен создать MSIL-файл, предназначенный для CLR, а также использовать библиотеки .Net Framework 3) ), при выполнении которых он получает множество преимуществ, включая современное управление памятью, способность совмещать языки, высокий уровень безопасности передачи данных, поддержку контроля версии и понятный способ взаимодействия компонентов программного обеспечения 4) .

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

    Конечно, компиляция не будет столь полезна, если ее выполнение будет необходимо каждый раз при запросе пользователем Web-страницы. К счастью, приложения ASP.NET не нужно компилировать всякий раз при запросе Web-страницы или Web-службы. Вместо этого код IL создается один раз и повторно генерируется только при изменении исходного кода. Подобным образом файлы собственного машинного кода кэшируются в системном каталоге с путем вроде С:\[WinDir]\Microsoft.NET\ Framework\[Version]\Temporary ASP.NET Files, где WinDir является каталогом Windows, a Version — номером установленной в данный момент версии .NET.

    Каждое Web-приложение, разрабатываемое на основе ASP.NET состоит из информационной части, программного кода и сведений о конфигурации.

    Информационная часть содержит статические и динамические элементы страницы и реализуется в виде Web-форм. Статические элементы представляют собой типичные элементы языка HTML, динамические же компонуются программным кодом приложения во время его выполнения (например, запросы к базе данных).

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

    Сведения о конфигурации представляют собой файлы, содержащие параметры, определяющие способ исполнения приложения на сервере, параметры безопасности, реакцию приложения на возникающие ошибки и т. д.

    Основным элементом Web-приложения является Web-форма (или Web-страница), которая, с одной стороны, похожа на Windows-форму, т. к. позволяет размещать внутри себя различные элементы управления, способные отображать данные и реагировать на действия пользователя, а с другой — представляет собой HTML-страницу, т. к. содержит все ее атрибуты. Описания элементов управления, упомянутых ранее, представляются в коде HTML-страницы в виде специальных тегов.

    На рис.1.4. представлен пример простейшей страницы Web-приложения, содержащего всего лишь один элемент — кнопку. Как видно из рисунка, основой страницы является тело стандартного HTML-документа, внутри которого находится элемент form, а также кнопка button. Кроме того, в начале документа здесь присутствуют некоторые дополнительные элементы, которые будут рассмотрены позднее.

    Рис. 1.4. Пример простейшей страницы Web-приложения

    При запуске приложения данная страница отображается в окне браузера и выглядит следующим образом (рис.1.5.).

    Рис. 1.5. Отображение страницы Web-приложения в окне браузера

    В свою очередь, с кнопкой связан программный код, который выполняется при нажатии на нее. Этот код располагается в отдельном файле, окно которого в момент разработки выглядит как на рис.1.6.

    Рис. 1.6. Файл, содержащий программный код Web-страницы

    На самом деле при разработке Web-приложений на основе ASP.NET возможны два варианта организации Web-форм.

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

    Во втором случае каждая Web-страница разделяется на две части: Web-форму и файл, содержащий программный код. При этом форма, как и в первом случае, сохраняется в файле с расширением .aspx, а программный код — в файле с расширением .cs. Такая модель обеспечивает лучшую организацию элементов Web-приложения за счет отделения пользовательского интерфейса от программной логики.

    В примере, рассмотренном ранее, Web-страница разделена на две части, при этом форма и программный код хранятся в разных файлах.

    В следующем примере, изображенном на рис.1.7., показана аналогичная предыдущей Web-страница, в которой форма и программный код объединены в одном файле.

    Рис. 1.7. Пример Web-формы, содержащей описание формы и программный код в одном файле

    Изучив этот пример, можно описать типовой сценарий взаимодействия элементов Web-приложения друг с другом и с клиентом, осуществляющим запрос формы этого приложения (рис 1.8).

    Рис. 1.8. Типовой сценарий взаимодействия элементов Web-приложения с клиентом

    Как видно из рис.1.8, при обращении клиента к Web-приложению последнее запускается на сервере IIS. Запущенное приложение формирует отклик. Для этого на сервере создается экземпляр запрошенной Web-формы, она генерирует HTML-текст отклика, который и передается браузеру клиента. Сразу после этого экземпляр Web-формы уничтожается. Пользователь, получив HTML-страницу, сгенерированную приложением, имеет возможность заполнять различные поля формы (тестовые поля, переключатели и т. п.). После заполнения всех необходимых полей формы пользователь инициирует отправку данных, введенных им в страницу, обратно на сервер. Это происходит за счет использования технологии обратной отсылки, которая вызывается при выполнении определенных действий (например, нажатия на кнопку). Получив данные от пользователя, сервер создает новый экземпляр Web-формы, заполняет его полученными данными и обрабатывает все необходимые события. По окончании обработки сервер формирует HTML-код ответа и отправляет его клиенту, а затем уничтожает экземпляр Web-формы. Более подробно описанный сценарий изображен на рис. 1.9 и 1.10

    Рис. 1.9. Подробный сценарий взаимодействия элементов Web-приложения с клиентом при первом запросе


    Рис. 1.10. Подробный сценарий взаимодействия элементов Web-приложения с клиентом при запросе обратной отсылки

    В момент окончания работы с Web-приложением пользователь либо закрывает браузер, либо переходит на другую интернет-страницу. В этот момент завершается сеанс работы пользователя с данным приложением, однако само приложение может быть завершено сервером не сразу после окончания последнего сеанса работы пользователя. Это связано с управлением распределением памяти платформой .NET Framework, которая основана на периодической проверке ссылок объектов. Если в результате такой проверки обнаружится, что объект больше не используется, сервер уничтожает его, освобождая таким образом занимаемую им память. Поэтому нельзя точно сказать, когда именно наступит событие Application_End для данного Web-приложения.

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

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

    Итак, при запросе страницы прежде всего инициируется событие Page_Init, которое производит начальную инициализацию страницы и ее объекта. В рамках обработки данного события программист может разместить код, осуществляющий начальную инициализацию страницы. Тем не менее это событие нельзя использовать для инициализации элементов управления, размещенных на странице, так как они еще не созданы.

    После этого инициируется событие Page_Load. Большинство Web-страниц используют это событие для выполнения инициализации, например, заполнения полей данными, установки начальных значений для элементов управления и т. д. Кроме того, в процедуре обработки данного события возможно определение того, была ли загружена страница впервые или обращение к ней осуществляется повторно в рамках технологии обратной отсылки, произошедшей в результате нажатия пользователем кнопки либо другого элемента управления, размещенного на странице. В английской терминологии обратная отсылка данных на сервер называется post back. Для определения текущего состояния страницы необходимо проверить свойство Page.IsPostBack, которое будет иметь значение false при первом запуске страницы. Определение того, производится ли первое обращение к данной странице либо повторное, важно, так как позволяет производить инициализацию только в том случае, когда страница запрашивается впервые. Так, например, при обратной отсылке данных на сервер не только нет необходимости производить инициализацию, устанавливая начальные значения элементов управления, но это даже может быть ошибкой, так как эти элементы управления должны получить значения, переданные им от пользователя. В дальнейшем, в случае, если для страницы была произведена обратная отсылка, вызываются события элементов управления, размещенных на странице. Эти события запоминаются в тот момент, когда пользователь производил действия с элементами управления в окне браузера, а при передаче данных на сервер исполняются по порядку.

    После вызова события Page_Load происходит так называемая проверка достоверности страницы. Необходимость такой проверки возникает тогда, когда пользователь ввел в элементы управления, расположенные на странице, данные, которые впоследствии необходимо сохранить или использовать для обработки. В идеале проверка достоверности должна происходить на стороне клиента, чтобы пользователь был проинформирован о проблемах с вводом данных перед их отправкой на сервер, т. к. это позволяет уменьшить объем информации, передаваемой по сети, и ускорить процесс обмена данными с сервером. Однако, независимо от того, была ли произведена проверка достоверности данных на стороне клиента или нет, ее необходимо осуществлять и на стороне сервера. Осуществление проверки достоверности — достаточно сложная задача. Сложность эта обусловлена различием моделей клиентского и серверного программирования. В ASP.NET существует несколько элементов управления проверкой достоверности. Они выполняют автоматическую клиентскую и серверную проверку. В случае, если проверка достоверности выявила ошибки во введенных данных, ASP.NET уведомит об этом пользователя и не позволит осуществлять дальнейшую работу со страницей до устранения ошибок. Более подробно организация проверки достоверности рассматривается в лекции 5.

    Следующим шагом обработки Web-формы является обработка всех событий, инициированных пользователем с момента последней обратной отсылки. Для иллюстрации этого приведем пример.

    Пусть у нас существует страница с кнопкой (Button) «Отправить» и текстовым полем (TextBox) без автоматической обратной отсылки. При изменении текста в текстовом поле и щелчке на кнопке «Отправить» инициируется обратная отправка данных страницы на сервер (этого не произошло при изменении текста в текстовом поле, так как соответствующая опция этого элемента управления AutoPostBack установлена в false). В момент обратной отправки страницы на сервер ASP.NET запускает следующие события:

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

    Описанная последовательность событий позволяет создать описание жизненного цикла Web-страницы, изображенного на рис 1.11.

    Рис. 1.11. Жизненный цикл страницы ASP.NET

    Вернемся, однако, к проблеме сохранения данных страницы в промежутке между обращениями к ней. Для реализации этого механизма в ASP.NET используются состояния отображения (view state). Состояние отображения Web-формы доступно только внутри этой Web-формы. Если необходимо сделать данные, введенные в Web-форму, доступными другим Web-формам одного и того же приложения, эти данные необходимо сохранить в объектах с более глобальной областью видимости, которые называют переменными состояния. Объектов переменных состояний два: Application и Session. Переменные состояния Application доступны всем пользователям приложения и могут рассматриваться как глобальные переменные, обращение к которым возможно из любых сеансов. Переменные состояния Session доступны только в рамках одного сеанса, и поэтому они оказываются доступными только одному пользователю. В переменных состояния можно хранить данные любого типа. В силу того, что переменные состояния фактически являются глобальными переменными, для работы с ними желательно выработать стратегию их использования в приложении.

    Более подробно работа с состояниями отображения и переменными состояния будет рассмотрена в разделе «Класс Page» в лекции 2.

    Web-приложения представляют собой особый тип программ, основанных на архитектуре «клиент-сервер». Web-приложение располагается и исполняется на сервере, получая от клиента исходные данные для работы, а также передавая ему результаты работы в виде HTML-кода, отображаемого в браузере.

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

    Каждое Web-приложение ASP.NET состоит из 3 частей: информационной, программного кода и сведений о конфигурации. Информационная часть включает в себя описание страницы в формате HTML и содержит как элементы языка гипертекстовой разметки документа, так и элементы ASP.NET. Программный код реализует бизнес-логику, оформленную в виде процедур обработки данных. Этот код исполняется сервером и взаимодействует с динамическими элементами информационной части, позволяя динамически формировать содержимое страницы, передаваемой клиенту. Сведения о конфигурации содержат параметры, определяющие способ исполнения приложения на сервере, параметры безопасности, реакцию на возникающие ошибки и др.

    Типовой сценарий взаимодействия Web-приложения с другим Web-приложением и с клиентом выглядит следующим образом: клиент посылает запрос на открытие страницы Web-приложения, Web-сервер осуществляет запуск приложения, создает экземпляр запрашиваемой клиентом формы, исполняет программный код, связанный с формой, формирует HTML-текст отклика, который и передает браузеру клиента, после чего уничтожает Web-форму. Пользователь просматривает переданную ему сервером страницу, при необходимости вводит данные в расположенные на ней поля ввода и инициирует их отправку на сервер. Сервер создает новый экземпляр формы приложения, заполняет поля данными, полученными от клиентского компьютера, формирует HTML-текст отклика и передает его клиенту.

    1) Благодаря архитектуре среды CLR в качестве операционной системы может выступать любая версия Unix и вообще любая ОС. 2) Сборка (assembly) – это коллекция файлов, которая предстает перед программистом в виде единой библиотеки динамической компоновки (DLL) или исполняемого файла (EXE). В технологии .NET сборка является базовой единицей для повторного использования, контроля версий, защиты и развертывания. Среда CLR представляет программисту ряд классов, позволяющих манипулировать сборками. 3) Библиотека классов .NET открывает доступ ко всем возможностям CLR. Классы, составляющие эту библиотеку, организованы при помощи пространств имен. Каждое пространство имен заключает в себе классы, выполняющие близкие функции. 4) Альтернативой управляемому коду является неуправляемый код, который не выполняется CLR. Однако до появления .NET Framework все Windows-программы использовали именно неуправляемый код.

    Создание Web-приложений с помощью C++Builder 5

    Данная статья посвящена одной из неплохо зарекомендовавших себя технологий создания динамических интерактивных Web-сайтов — разработке CGI- и ISAPI-приложений. Будучи далеко не единственной технологией создания таких Web-сайтов, она тем не менее остается довольно популярной. В данной статье мы рассмотрим примеры создания CGI- и ISAPI-приложений, выполняемых под управлением Microsoft Internet Information Services, с помощью C++Builder 5. О других способах создания динамических Web-сайтов, например разработке ASP-приложений, вы можете прочитать в статье Сергея Трепалина «Создание серверных компонентов для ASP-приложений» на этом же CD-ROM.

    Web-приложения (называемые также скриптами) представляют собой исполняемые файлы или библиотеки, выполняемые под управлением Web-сервера. Их назначение — в ответ на запросы пользователя динамически генерировать HTML-страницы, которые будут интерпретироваться Web-браузером.

    Применение Интернета в широком смысле означает доступ к ресурсам, содержащимся в Сети. Любой ресурс Интернета однозначно идентифицируется с помощью адреса URL (Uniform Resource Locators), который можно ввести в соответствующем поле браузера либо выбрать, щелкнув мышью на гипертекстовой ссылке Web-страницы или другого документа. Примерами Интернет-ресурсов являются HTML-страницы, документы различных форматов, Java-аплеты, элементы управления ActiveX и другие файлы. Результат выполнения какого-либо приложения, управляемого Web-сервером, также является ресурсом Интернета, и если настройки уровня безопасности браузера позволяют использовать этот ресурс, он также будет интерпретирован браузером. Отметим, что приложения, выполняемые под управлением Web-серверов и являющиеся источником подобных ресурсов, способны обрабатывать параметры, содержащиеся в запросе пользователя, и результат их работы может зависеть от этих параметров.

    Создать Web-приложение, динамически генерирующее подобные ресурсы (обычно HTML-документы), можно с помощью практически любого средства разработки — лишь бы оно позволяло создавать приложения для той операционной системы, в которой работает Web-сервер. Однако если вы хотите снизить трудозатраты, связанные с созданием таких приложений, то имеет смысл обратить внимание на средства разработки, позволяющие их минимизировать. С этой точки зрения довольно удачным выбором являются Borland Delphi 5 и Borland C++Builder 5 (редакции Enterprise и Professional), а также Delphi 4 и C++Builder 4 Enterprise, так как эти средства разработки содержат неплохие визуальные инструменты и компоненты для создания подобных приложений.

    Рассматриваемые в настоящей статье примеры или их аналоги, если это особо не оговорено, можно создавать с помощью любого из перечисленных выше средств разработки. Сами примеры созданы с помощью C++Builder 5 Enterprise, но, думаю, пользователям Delphi не составит особого труда перенести их код на Object Pascal. Архив с примерами можно найти здесь.

    Изучение разработки Web-приложений мы начнем с создания простейшего примера.

    Простейшее Web-приложение

    Для создания простейшего Web-приложения из главного меню среды разработки C++Builder выберем пункт File | New и в репозитарии объектов выберем пиктограмму Web Server Application (рис. 1).

    Далее нужно выбрать тип приложения (исполняемый файл CGI или Win-CGI либо динамически загружаемая библиотека ISAPI/NSAPI DLL, представляющая собой функциональное расширение для Microsoft Internet Information Services или Netscape FastTrack). CGI-скрипт (CGI-Common Gateway Interface), будучи исполняемым файлом, запускается в отдельном процессе, в то время как ISAPI/NSAPI DLL (динамически загружаемая библиотека — выполняется в адресном пространстве Web-сервера. Поэтому ISAPI/NSAPI DLL требуют меньше ресурсов, чем CGI-скрипты. К тому же такие библиотеки после загрузки остаются в памяти сервера, что уменьшает время их отклика на последующие обращения к ним. Однако это мешает их отладке: после внесения в библиотеку каких-либо изменений необходим перезапуск Web-сервера. В связи с этим при разработке Web-приложений нередко сначала создается CGI-скрипт, который затем отлаживается, после чего на основе имеющихся модулей создается ISAPI/NSAPI DLL. Так мы и поступим: выберем опцию CGI Stand-alone executable и создадим Win32-консольное приложение для генерации HTML-документов. В результате получим объект TWebModule, напоминающий обычный модуль данных (рис. 2).

    Рассмотрим, как работает Web-приложение. Если Web-сервер получает от браузера запрос, соответствующий спецификации CGI, он инициирует запуск CGI-приложения для его выполнения. Если запрос корректен, CGI-приложение обрабатывает его и генерирует HTML-документ, который отсылается Web-сервером обратно в браузер. Для обмена данными между браузером и сервером используется протокол HTTP (HyperText Transfer Protocol).

    Когда Web-приложение получает HTTP-запрос, оно создает объект TWebRequest для представления запроса и объект TWebResponce для представления отклика, отправляемого в браузер пользователя. Затем оба объекта передаются объекту TWebModule (рис. 3).

    Объект TWebModule содержит набор объектов TWebActionItems, хранящих информацию о том, как обрабатывать различные пользовательские запросы. Опознав запрос, он выбирает нужный из них и выполняет соответствующий обработчик события OnAction, обрабатывающий запрос и динамически генерирующий ответ, который передается Web-сервером в браузер пользователя.

    Для того чтобы приложение было работоспособным, создадим хотя бы один объект TWebActionItem, реализующий отклик на пользовательский запрос. С этой целью из контекстного меню объекта TWebModule надо выбрать пункт Action Editor и нажать кнопку Add в появившейся форме. Далее можно установить свойства PathInfo и Default объекта WebActionItem1. Первое свойство является частью URL (Uniform Resource Locator) — полного описания доступа к ресурсу (рис. 4).

    Свойство Default указывает, выполняется ли данный отклик, если параметр PathInfo в пользовательском запросе остался пустым (рис. 5).

    Теперь создадим обработчик события OnAction компонента TWebActionItem:

    В этом обработчике события генерируется содержащая текущее время HTML-страница примерно следующего вида (рис. 6):

    Сделаем одно небольшое, но важное замечание. Перед компиляцией такого приложения в С++Builder в опциях проекта следует отключить опцию Use dynamic RTL на странице Linker. Кроме того, стоит отключить и опцию Build with runtime packages на странице Packages либо поместить все эти библиотеки в тот же каталог, что и само приложение (рис. 7).

    Дело в том, что запустить такое приложение из командной строки можно без проблем, при этом оно обращается к RTL и «пакетам», находящимся за пределами каталогов Web-сервера. Однако запустить его с помощью Web-сервера скорее всего не удастся — все эти файлы окажутся недоступны. В этом случае вместо ожидаемого результата выполнения приложения будет получено сообщение об ошибке примерно следующего вида:

    CGI Error
    The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: .

    Отметим, что при создании ISAPI DLL с использованием Delphi 4 или C++Builder 4 в такой библиотеке не должно быть «пакетов» — она обязательно должна состоять из одного файла.

    После компиляции приложения можно сохранить полученный исполняемый файл в каталоге, предназначенном для Web-приложений (в случае MS Internet Information Services по умолчанию это каталог C:\Inetpub\scripts). Затем можно обратиться к приложению через Web-браузер, указав URL-приложения. Обратите внимание: внешнему пользователю, обращающемуся к созданному приложению через браузер, не видна (и не должна быть видна) структура каталогов компьютера, содержащего Web-сервер, — вместо этого ему следует вводить их псевдонимы. Такой подход к использованию каталогов Web-сервера необходим для обеспечения безопасности — внешний пользователь ничего не должен знать о файлах и каталогах компьютера, содержащего Web-сервер, кроме того что ему положено.

    Запустив приложение, можно нажать кнопку Reload и убедиться, что текст в браузере меняется. Это значит, что страница генерируется динамически (рис. 8).

    Из этого CGI-скрипта мы можем создать ISAPI DLL. Для этого следует создать новое Web-приложение в виде ISAPI DLL, удалить из него объект TWebModule, а вместо него добавить другой объект TWebModule из предыдущего проекта.

    Создание форм и обработка пользовательского ввода

    Отметим, что объект TWebModule существенно облегчает создание CGI-приложений, связанных с обработкой пользовательского ввода (например, в HTML-формах), заключающегося в изменении или добавлении данных. Типичными примерами таких приложений являются анкеты, которые в изобилии встречаются на многих Web-серверах. Дополним наше приложение такой анкетой.

    Для отображения в браузере формы ввода данных пользователем создадим еще один компонент TWebActionItem (рис. 9):

    Установим свойство Default вновь созданного объекта TWebAction равным True. Теперь добавим в WebModule1 компонент TPageProducer, назначение которого — генерировать HTML-документ на основе заранее заданного шаблона (рис. 10).

    Для создания шаблона документа можно воспользоваться любым HTML-редактором, поддерживающим создание форм, например Microsoft FrontPage (рис. 11).

    Исходный текст формы, представленной на рис. 11, имеет вид:

    Созданный документ можно сохранить в виде файла (и указать его имя в качестве свойства HTMLFile компонента TPageProducer). Можно также скопировать HTML-текст в буфер обмена и поместить его в редактор свойства HTMLDoc этого компонента.

    Теперь создадим обработчик события OnAction сгенерированного нами компонента TWebActionItem2:

    Отметим, что в Delphi 5 и C++Builder 5 компонент TWebAction имеет свойство Producer, позволяющее непосредственно указать, какую именно HTML-страницу нужно генерировать при обращении. Это во многих случаях избавляет от необходимости создавать обработчик события OnAction данного компонента.

    Сохранив проект, можно снова обратиться к нему с помощью браузера, указав значение PathInfo в URL (рис. 12):

    Теперь осталось обработать пользовательский ввод, например, динамически сгенерировав страницу с введенными пользователем значениями. С этой целью добавим еще один компонент — TPageProducer (рис. 13): страницы, содержащей результаты обработки пользовательского ввода

    В качестве значения свойства HTMLDoc вновь созданного компонента PageProducer2 введем следующий текст:

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

    Для замены специальных тэгов следует создать обработчик события OnHTMLTag компонента PageProducer2:

    Здесь Request — объект TWebRequest, сгенерированный приложением в результате пользовательского запроса. В свойстве QueryFields (объект TStrings) этого объекта содержатся имена параметров и значения, введенные пользователем, в виде Name=Value (реально они содержатся в переменной окружения QUERY_STRING, созданной Web-сервером, в виде Name1=Value1&Name2=Value2&…). Параметр TagString — строка, содержащаяся в тэге, подлежащем замене. Cвойство Values объекта TStrings используется, если строки, содержащиеся в этом объекте, представимы в виде Name=Value (что и происходит в данном случае).

    Отметим, что если в тэге , содержащемся в тексте формы, вместо метода GET указан метод POST, то вместо свойства QueryFields следует использовать свойство ContentField.

    Теперь создадим еще один компонент TWebAction (со значением свойства PathInfo, равным /test3) для отображения страницы, сгенерированной с помощью PageProducer2, и добавим еще один обработчик события OnAction:

    Возникает вопрос: каким образом можно инициировать генерацию этой страницы после нажатия пользователем кнопки Submit в форме ввода? С этой целью следует описать реакцию на ее нажатие в HTML-тексте формы, то есть отредактировать свойство HTMLDoc компонента PageProducer1:

    В параметре action указывается URL ресурса, предоставляемого при нажатии кнопки Submit. В данном случае это наше приложение со значением PathInfo, равным /test3 (естественно, имя Web-сервера, так же как и другие части URL, может быть другим).

    Теперь можно снова скомпилировать и сохранить приложение. Обратившись к нему с помощью браузера и заполнив форму, нажмем на кнопку Submit. В результате получим страницу, сгенерированную динамически на основе введенных в форму данных (рис. 14):

    Из этого CGI-скрипта, как и в предыдущем случае, можно создать ISAPI DLL.

    Применение баз данных в Web-приложениях

    Мы можем создать код, позволяющий добавлять записи в какую-нибудь таблицу, в созданный ранее обработчик события WebModule1WebActionItem3Action (и таким образом действительно получить простейший список рассылки). Для этого необходимо добавить некоторые из компонентов доступа к данным в WebModule1 и установить соответствующие свойства (рис. 15):

    Перепишем созданный ранее обработчик события WebModule1WebActionItem3Action:

    Теперь наше приложение сохраняет пользовательский ввод в таблице базы данных. Чтобы убедиться в этом, можно скомпилировать, а затем протестировать приложение.

    Мы рассмотрели простейший пример использования баз данных в Web-приложениях. Но, как правило, требуется публикация данных в Интернете и представление их в браузере. Для этой цели используются компоненты TDataSetTableProducer и TQueryTableProducer, получающие данные либо из компонентов TDataSet, либо c помощью запроса к базе данных и представляющие их в виде HTML-документа в табличном виде.

    Для создания приложений, осуществляющих публикацию данных в Интернете, можно воспользоваться «мастером» DB Web Application Wizard со страницы Business репозитария объектов (рис. 16).

    DB Web Application Wizard представляет собой последовательность диалоговых панелей, в которых следует выбирать базу данных, таблицу и публикуемые поля (рис. 17).

    После заполнения всех форм мы получим компонент TWebModule, в который входят компоненты TTable (или TQuery), TSession и TDataSetPageProducer. Этого достаточно для создания простейшего приложения для публикации данных. Выглядеть оно будет примерно так, как показано на рис. 18.

    Таблица, выбранная для этого примера (biolife.db из базы данных BCDEMOS), содержит графические поля. Рассмотрим варианты отображения их в таблице.

    Один из способов решения этой проблемы — создание в таблице вычисляемого поля, содержащего соответствующий HTML-тэг со ссылкой на графический файл, полученный на основе изображения, извлеченного из соответствующей записи. Именно так мы и поступим. Кроме того, необходимо учитывать, что несколько человек могут обратиться к одной и той же таблице с разными запросами одновременно, поэтому конкретный пользователь не должен видеть в своем браузере изображения, которые ему не предназначены. Этого можно достичь, например, присвоив файлам с изображениями уникальные имена. Обработчик события OnCalcField для компонента Table1, реализующий этот прием, может выглядеть, например, так:

    Необходимо также сослаться на соответствующий h-файл:

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

    Может возникнуть вопрос: почему файл с графическим изображением не удаляется в обработчике события OnCalcFields? Дело в том, что изображение может быть загружено в браузер намного позже, чем приложение завершит свою работу (особенно если пользователь имеет доступ в Интернет по обычной телефонной линии с помощью модемного соединения). Это означает, что файлы с изображениями после окончания работы приложения должны храниться на жестком диске Web-сервера. Поэтому удаляться они должны другим приложением либо просто другим экземпляром того же самого приложения, запущенным позже. Пример кода, реализующего удаление ненужных файлов с графическими изображениями в предположении, что для загрузки всех изображений в браузер конкретного пользователя достаточно десяти минут, приведен ниже:

    В обработчике события OnCrerate нашего объекта TWebModule удаляем все изображения, хранящиеся в каталоге Web-приложения более десяти минут, и инициализируем генератор случайных чисел.

    Отметим, что каталог, в котором размещены файлы с графическими изображениями, должен быть доступен для чтения пользователями Интернета. Поскольку в нашем примере это тот же самый каталог, где находится исполняемый файл, не исключено, что для работоспособности этого приложения нужно внести соответствующие изменения в настройки каталогов Web-сервера — например, каталог Scripts Internet Information Services, где обычно помещают Web-приложения, по умолчанию такого разрешения не имеет. Однако с точки зрения безопасности более оправданно размещение файлов с изображениями в другом каталоге.

    Наконец, щелкнем правой клавишей мыши на компоненте TDataSetTableProducer, выберем опцию Response Editor и изменим вид HTML-таблицы (рис. 19).

    Можно, например, изменить свойства Cellpadding, Cellspacing, Border, BgColor HTML-таблицы, отвечающие за расстояние между ячейками, их цвет, толщину линий сетки. Кроме того, мы можем сгенерировать объекты THTMLTableColumn и изменить их свойства, что позволит установить свои правила отображения колонок таблицы и их заголовков.

    Теперь можно сохранить, скомпилировать и протестировать приложение. Результат изображен на рис. 20.

    Выполнение всех рассмотренных выше примеров возможно с помощью Delphi 5 и C++Builder 5 Enterprise и Professional, а также Delphi 4 и C++Builder 4 Enterprise. Пример, который будет рассмотрен в следующей части статьи, можно выполнить только посредством Delphi 5 и C++Builder 5 Enterprise, поскольку в нем использованы компоненты InternetExpress, отсутствующие в других версиях этих средств разработки.

    Интерактивные формы для редактирования данных

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

    Несколько иначе обстоит дело с более интерактивным Web-приложением, которое позволяет, как минимум, не обращаться к серверу для проверки соответствия введенных данных каким-либо банальным требованиям типа отсутствия букв в числовом поле, а также контролирует корректность введенных данных в момент, когда фокус ввода покидает данное поле, а не когда вся запись отправляется на сервер. Пути достижения этой цели известны, и наиболее распространенным из них является применение скриптовых языков (VBScript или JavaScript). Фрагменты кода на этих языках, содержащие логику проверки корректности данных, могут находиться в HTML-странице, и при отображении в браузере они интерпретируются им, позволяя произвести такую проверку без обращения к серверу. В этом случае наше CGI- или ISAPI-приложение должно «уметь» генерировать страницы, содержащие код на одном из этих языков.

    В принципе, при наличии времени и знаний одного из скриптовых языков создать интерактивный аналог приведенных выше примеров не так уж сложно. Однако при наличии Delphi 5 или C++Builder 5 Enterprise добиться интерактивности можно более простым способом. Этот способ заключается в применении компонентов InternetExpress, которые предназначены для создания MIDAS-клиентов, являющихся Web-приложениями. Подобные приложения обмениваются XML-данными с браузерами, поддерживающими интерпретацию кода JavaScript. Подробности о MIDAS-приложениях подобного типа можно узнать из статьи «MIDAS3: новые возможности» (КомпьютерПресс, № 1’2000).

    Отметим, что применение компонентов InternetExpress не ограничено только «истинными» MIDAS-приложениями с отдельным сервером доступа к данным — с помощью этих компонентов можно создать Web-приложение, являющееся обычным клиентом серверной СУБД. Однако подобное приложение более интерактивно, чем традиционное HTML-приложение, и ниже мы увидим, в чем это выражается.

    Итак, создадим простейшее приложение, иллюстрирующее применение компонентов InternetExpress. В этом примере мы поместим MIDAS-сервер и MIDAS-клиент в одно и то же приложение. Для этого создадим новое CGI-приложение и поместим компоненты TTable и TDataSetProvider в объект TWebModule — они представляют собой «серверную» часть этого приложения. Теперь необходимо установить значения свойств DatabaseName и TableName компонента Table1 (например, BCDEMOS и Customers.db). Далее следует установить значение свойства DataSet компонента DataSetProvider1 равным Table1 — это означает, что компонент Table1 теперь доступен для будущих MIDAS-клиентов.

    Теперь поместим в тот же самый объект TWebModule компоненты TXMLBroker и TmidasPageProducer, представляющие собой «клиентскую» часть нашегоWeb-приложения. Первый из них отвечает за получение пакетов данных от MIDAS-сервера, а второй — за генерацию Web-страницы, направляемой в браузер. В данном примере MIDAS-сервер находится внутри нашего же приложения, поэтому установим значение свойства ProviderName компонента XMLBroker1 равным DataSetProvider1, оставив свойство RemoteServer пустым (рис. 21).

    Далее необходимо выбрать пункт Web Page Editor из контекстного меню компонента MidasPageProducer1. Этот редактор свойств позволяет указать, какие интерфейсные элементы для отображения и редактирования данных нужно отображать в браузере. Например, добавим в него компонент DataForm с вложенными в него компонентами FiedlGroup и DataNavigator. Установим значение свойства XMLBroker компонента FieldGroup1 равным XMLBroker1, а свойства XMLComponent компонента DataNavigator1FieldGroup1 (рис. 22).

    Следующим шагом будет установка значения свойства IncludePathURL компонента MidasPageProducer1. Это URL, где наше Web-приложение должно найти JavaScript- и HTML-файлы, используемые для генерации Web-страниц. Файлы *.js и *.html следует скопировать из каталога Cbuilder5\Source\Webmidas в каталог, соответствующий этому URL.

    Следует заметить, что каталог Inetpub\Scripts, являющийся по умолчанию каталогом для Web-приложений Microsoft Internet Information Services и, следовательно, потенциальным местом для размещения нашего Web-приложения, — не самое подходящее место для данных файлов. Дело в том, что по умолчанию файлы из этого каталога можно запускать на выполнение, но они недоступны для чтения. Поэтому нужно изменить настройки этого каталога или, что более предпочтительно, использовать другой каталог.

    Наконец, следует создать объект TWebActionItem, установить значение его свойства Default равным true, а значение свойства ProducerMidasPageProducer1. Наше приложение готово.

    Теперь можно сохранить проект, скомпилировать его и перенести исполняемый файл в соответствующий каталог Web-сервера. Результат выполнения данного приложения показан на рис. 23.

    Теперь осталось рассмотреть, почему полученное приложение более интерактивно, чем приложение, результат выполнения которого изображен на рис. 12. Анализ поведения последнего приложения показывает, что оно позволяет редактировать одновременно несколько записей, перемещаться между ними, использовать кнопки Undo или Post, добавлять и удалять записи – и все это без обращения к Web-серверу. Только нажатие кнопки ApplyUpdates инициирует новый запуск Web-приложения для того, чтобы сохранить внесенные пользователем изменения в базе данных. Если внимательно рассмотреть текст Web-страницы, генерируемый этим приложением, можно увидеть фрагменты кода JavaScript, а также XML-данные, соответствующие содержимому таблицы или запроса (их объем можно ограничить свойством MaxRecords компонента TXMLBroker). Поскольку код JavaScript интерпретируется браузером, а все необходимые данные содержатся внутри Web-страницы, при перемещении по записям и их редактировании нет необходимости обращаться к Web-серверу, пока пользователю не потребуется новая порция записей из базы данных. Это означает, что InternetExpress-приложения более интерактивны, чем HTML-приложения.

    Заключение

    В данной статье мы рассмотрели создание наиболее часто встречающихся типов Web-приложений с помощью C++Builder. Изучили, как динамически генерировать Web-страницы, обрабатывать пользовательский ввод и сохранять его в базе данных, как публиковать данные в Интернете и организовать вывод графических изображений. Наконец, мы обсудили, как создать интерактивное Web-приложение для редактирования данных.

    Следует заметить, что создание приложений подобного класса возможно с помощью не только средств разработки Borland, но и большинства других (Microsoft Visual Basic, Sybase PowerBuilder, Microsoft Visual FoxPro и т.д.). Названия классов, применяемых при генерировании таких приложений, могут быть иными, но основные принципы остаются примерно теми же, что и в приведенных примерах.

    В заключение отметим, что CGI/ISAPI — не единственная технология создания Web-приложений, содержащих код, исполняемый на Web-сервере. В настоящее время все более популярной становится технология ASP (Active Server Pages), позволяющая включать результат выполнения серверного кода в Web-страницы. Подробнее об этом можно прочитать в других статьях, в частности в статье Сергея Трепалина «Создание серверных компонентов для ASP-приложений» на нашем CD-ROM.

    Как создать приложение IIS и пул приложений с помощью Inno Setup script

    Я пытаюсь развернуть приложение ASP.NET с помощью Inno Setup.

    Мне нужно выполнить следующие задачи:

    • Создайте приложение IIS.
    • Создайте новый пул приложений IIS и установите версию .NET на 4.
    • Установить пул приложений нового приложения в новый пул приложений.

    Я нашел script для создания виртуального каталога, но мне нужен пул приложений и приложений:

    Вопрос задавался давно, но, возможно, кто-нибудь найдет этот script для IIS6/IIS7 полезным:

    Прокрутите вниз Create Application Pool . Он покажет вам, как создать AppPool, Application и VirtualDirectories.

    Публикация на IIS с помощью Web Deploy и Visual Studio¶

    Публикация ASP.NET Core проекта на IIS с помощью Web Deploy требует нескольких дополнительных шагов по сравнению с проектом ASP.NET 4. Вы можете использовать эти инструкции, чтобы опубликовать ASP.NET Core веб приложение с помощью Web Deploy на любом IIS хосте.

    Чтобы опубликовать ASP.NET Core приложение на удаленном IIS сервере, нужно сделать следующее:

    1. Настроить удаленный IIS сервер для поддержки ASP.NET Core
    2. Создать профиль публикации
    3. Настроить профиль для поддержки Web Deploy

    Здесь мы пройдем каждый этап.

    Подготовка веб сервера для ASP.NET Core¶

    Во-первых, удаленный сервер должен быть настроен для ASP.NET Core. На высоком уровне вам нужны:

    1. IIS сервер с IIS 7.5+
    2. Установить HttpPlatformHandler
    3. Установить Web Deploy v3.6

    HttpPlatformHandler — это новый компонент, который соединяет IIS с ASP.NET Core приложением. Вы можете получить его следующим образом.

    В дополнении к установке HttpPlatformHandler вам нужно установить последнюю версию Web Deploy (версию 3.6). Чтобы установить Web Deploy 3.6, вы можете использовать Web Platform Installer (WebPI) или напрямую скачать это. Но лучше всего использовать WebPI. WebPI предлагает установку и настройку хостинговых провайдеров.

    Настройка защиты данных¶

    Чтобы сохранить ключи защиты данных, вы должны создать реестр для каждого пула приложения. Вы должны использовать скрипт ` Provisioning PowerShell `_для каждого пула приложения, под которым вы будете хостить ASP.NET Core приложение.

    Для веб ферм разработчики могут настроить приложения, чтобы они использовали путь UNC для хранения ключей. По умолчанию ключи не шифруются. Вы можете развернуть на каждой машине сертификат x509 и использовать его для шифрования. См. конфигурационные API .

    Защита данных используется различным связующим ПО ASP.NET, включая то, которое используется при аутентификации. Даже если вы специально не вызываете API защиты данных из кода, вы должны настроить защиту данных с помощью скрипта или в коде. Если вы не настроите защиту данных при использовании IIS, ключи будут храниться in-memory и сбрасываться при закрытии или перезапуске приложения. Тогда, например, любые куки, созданные для аутентификации, станут недействительными, и пользователям придется логиниться снова.

    См. Публикация на IIS. Теперь давайте пойдем дальше.

    Публикация с помощью Visual Studio¶

    После настройки веб сервера вы должны создать профиль публикации в Visual Studio. Проще всего использовать пользовательский профиль при публикации ASP.NET Core приложения на стандартный IIS хост. Если у вашего провайдера есть право на создание профиля публикации, скачайте его, а затем импортируйте в диалоговое окно Visual Studio при помощи кнопки Import. Вы увидите это.

    После импорта публикационного профиля нужно предпринять еще один шаг, прежде чем мы сможем публиковать на стандартном IIS хосте. В сгенерированном скрипте PowerShell (в PropertiesPublishProfiles) обновите номер версии публикационного модуля с 1.0.1 на 1.0.2-beta2 . После изменения 1.0.1 на 1.0.2-beta2 вы можете использовать Visual Studio для публикации.

    Илон Маск рекомендует:  Что такое код gzencode
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL
    Название: работа Построение веб-приложения на основе asp. Net и архитектуры сервера iis 0
    Раздел: Остальные рефераты
    Тип: реферат Добавлен 07:15:35 30 августа 2011 Похожие работы
    Просмотров: 170 Комментариев: 6 Оценило: 1 человек Средний балл: 4 Оценка: неизвестно Скачать