C# для профессионалов. Том II
Шрифт:
Задавая значение
будет вызываться, как только изменится статус электропитания. Некоторые из значений, получаемые из
| Значение powerStatus | Описание |
|---|---|
BatteryLow | Слабый заряд батареи. Необходимо сократить функционирование службы до минимума. |
PowerStatusChange | Произошло
|
QuerySuspend | Полномочия системных запросов перешли в приостановленный режим. Можно отказаться от полномочий или приготовиться к переходу в приостановленный режим, закрывая файлы, разъединяя сетевые соединения и т.д. |
QuerySuspendFailed | Переход в приостановленный режим был отвергнут системой. Можно продолжать с той же функциональностью. |
Suspend | Никто не отменил запрос перехода в приостановленный режим. Система скоро будет приостановлена. |
Восстановление
Автоматическое восстановление является вопросом конфигурации, оно используется для всех свойств выполняющихся в системе Windows 2000. Если процесс службы разрушается, то служба автоматически запускается снова или конфигурируется специальный файл, или автоматически перезагружается вся система. Обычно существует причина разрушения службы, и нежелательно автоматически непрерывно перезагружать систему, поэтому нужно разнообразить ответы на первую, вторую и последующие ошибки.
Приложения COM+ в роли служб
Начиная с Windows ХР (кодовое имя Whistler), приложение COM+ выполняется как служба. В Windows ХР служба имеет прямой доступ к таким службам COM+, как транзакции, пулы объектов, пулы потоков выполнения и т.д. Если желательно использовать службы COM+ в Windows 2000 как службы Windows, то создаются два отдельных приложения: одно имеет дело с функциями службы, а второе — со службами COM+. Это нам дает некоторые преимущества:
□ Легче создать служебное приложение. Нам не нужно больше иметь дело со специальной установкой службы, так как это выполняется прямо из конфигурации COM+.
□ Приложение COM+ может действовать как служба. Оно автоматически запускается во время начальной загрузки, имеет права учетной записи System и реагирует на управляющие коды службы, которые посылаются из управляющей программы службы.
□ Служебное приложение, создаваемое как приложение COM+, имеет прямой доступ к таким службам COM+, как управление транзакциями, пулы объектов, пулы потоков выполнения и т.д.
Больше о службах COM+ можно прочитать в главе 20.
Заключение
В этой главе было показано, что такое службы Windows и как они создаются с помощью .NET Framework. Приложения в службах Windows запускаются автоматически во время начальной загрузки, и мы можем использовать привилегированную учетную запись System в качестве пользователя службы. .NET Framework обладает хорошей поддержкой служб. Весь вспомогательный код, который требуется для создания, управления и установки служб, находится в классах .NET Framework в пространстве имен
Глава 25
Система безопасности .NET
Вы садите за компьютером и работаете с приложением. За сценой приложение реагирует на тот факт, что вы пытаетесь использовать свойство, для которого у приложения нет подходящего модуля. Оно соединяется с Интернетом, загружает модуль в глобальный кэш сборок и начинает выполнение, и все это происходит без взаимодействия с пользователем.
Этот вид неявного обновления станет нормой в недалеком будущем, но очевидно, что здесь существуют проблемы, связанные с безопасностью так называемого мобильного кода. Какие имеются доказательства, что загруженный код надежен? Как узнать, что был получен именно тот модуль, который был запрошен? Что неявно делает CLR, чтобы гарантировать, например, что элемент управления на сайте Web не читает нашу почту?
Платформа .NET реализует политику системы безопасности в сборках. Она использует информацию о сборках, например, откуда они и кем опубликованы, чтобы разделить их на группы кодов с общими характеристиками. Например, весь код из локальной интранет помещается в единую группу. Он использует политику безопасности (обычно определяемую системным администратором с помощью утилиты caspol.exe или ММС) для назначения привилегий.
Политика безопасности .NET в сборках позволяет убедиться, что сборка исходит от того, кто ее опубликовал, и распределена между группами с одинаковыми характеристиками. Что необходимо сделать, чтобы инициировать систему безопасности для машины или для определенного приложения? Ничего — весь код автоматически выполняется в контексте безопасности CLR, хотя и возможно отключение системы безопасности по какой-либо причине.
В дополнение к уверенности в том, что выполняемый код надежен, также важно знать, что мы предоставляем пользователю приложения доступ к требуемым ему свойствам, но не более того. В эффективном управлении пользователями и их ролями может помочь система безопасности .NET на основе ролей.
В этой главе мы обсудим свойства управления безопасностью, доступные в .NET, включая защиту от злонамеренного кода, администрирование политиками безопасности и программный доступ к подсистеме безопасности. Мы также рассмотрим развертывание системы безопасности приложений .NET в коротких примерах приложений, которые закрепят концепции этой главы.
Система безопасности доступа к коду
Система безопасности доступа к коду является свойством .NET, которое управляет кодом в зависимости от нашего уровня доверия ему. Если система CLR достаточно доверяет коду, она начнет его выполнение. Однако в зависимости от полномочий, предоставленных сборкой, это может происходить в ограниченной среде. Если код недостаточно надежен для выполнения, или если он реализуется, но затем пытается выполнить действие, для которого не имеет соответствующих прав, порождается исключение безопасности (типа
Например, если пользователь пытается выполнить приложение, в котором помещен код, загруженный из Интернета, то используемая по умолчанию политика безопасности инициирует исключение и приложение невозможно будет запустить. Аналогичным образом, пользователь, работающий с приложением с сетевого диска, может начать его выполнение, но если приложение попытается обратиться к файлу на локальном диске, возникнет исключение и в зависимости от обработки ошибок в приложении оно либо аккуратно обработается, либо будет завершено.