Асинхронное прослушивание
Прежде чем вы сможете использовать функцию сигнализации API isc_que_evento, вам нужно выполнить функцию обратного вызова на клиенте, которую вызывал бы сервер при посылке события. Названием для такого типа функции является асинхронный перехват, или AST.
Функция AST предоставляет некоторую форму глобальных флагов для оповещения приложения, когда к нему обращается сервер. Она обрабатывает список событий сервера в буферах, к которым приложение может иметь доступ при управлении собственной очередью событий. Функция должна получать три аргумента:
* копию списка отправленных событий;
* длину буфера events_list;
* указатель на буфер events_iist.
Документ InterBase API Guide[128] содержит рекомендации по написанию функций AST.
Функция isc_event_biock() принимает в своем параметре isc caiiback указатель на функцию AST и в своем параметре event_function_arg- указатель на первый аргумент AST. Этот аргумент обычно получает значение счетчика событий, когда они изменяются.
Когда приложение вызывает функцию isc_que_events о для сообщения о событиях, которые оно будет ожидать, оно передает вместе со списком указатель на функцию обратного вызова AST. Один вызов isc_que_events() может содержать до 15 событий. Приложение вызывает функцию isc_event_counts() для определения того, какое событие произошло.
Множество вызовов isc que eventso может выполняться одновременно в одном процессе клиент-сервер. Приложения отключают режим ожидания при вызове функции isc_cancel_events().
! ! !
ПРИМЕЧАНИЕ. Подробности установки блока событий для синхронного прослушивания через isc_event_wait() такие же. События не являются постоянными, как при асинхронной технике isc_que_events(). Синхронная сигнализация не требует внешней функции AST.
. ! .
К счастью, почти для всех из нас фрагменты кодов для реализации событий в клиентских приложениях инкапсулированы в классах и компонентах в большинстве инструментов разработки приложений, которые поддерживают Firebird. Такие компоненты, включающие в себя AST, инкапсулирующие вызовы функций API isc_event* вместе с блоками параметров событий и управление буферами событий на клиентской стороне, обычно называются обработчиками сообщений (event alerter). Иногда этот термин в форумах и литературе вызывает путаницу, потому что триггеры и хранимые процедуры, вызывающие POST_EVENT, также часто называют обработчиками сообщений.
Использование POST_EVENT
Для использования обработчика сообщений в хранимой процедуре или триггере применяйте следующий синтаксис:
POST_EVENT <имя-события>;
Параметр <имя-события> может быть или литералом в кавычках, или строковой переменной. Он является чувствительным к регистру и может начинаться с цифры. Имена событий ограничиваются 64 символами.
При выполнении процедуры этот оператор сообщает о событии менеджеру событий, который сохраняет его в таблице событий. При подтверждении транзакции менеджер событий информирует приложения, ожидающие это событие. Например, следующий оператор посылает событие с именем new_order:
POST_EVENT ' new_order' ;
В альтернативном варианте, при использовании переменной для имени события можно одним оператором посылать различные события в соответствии с текущим значением строковой переменной (например, event_name).
POST EVENT event name;
! ! !
ПРИМЕЧАНИЕ. Хотя POST_EVENT и является оператором SQL, его аргумент имя события не должен иметь префикс двоеточия.
. ! .
Триггер или хранимая процедура, которые посылают сообщение, иногда называются обработчиками сообщений[129]. Следующий скрипт создает триггер, который посылает событие менеджеру событий, когда любое приложение добавляет в таблицу данные:
SET TERM А;
CREATE TRIGGER POST_NEW_ORDER FOR SALES ACTIVE AFTER INSERT POSITION 0
AS
BEGIN
POST_EVENT 'new_order'; END ^
SET TERM ; ^
Оператор POST EVENT доступен и в триггерах, и в хранимых процедурах. Как же решить, где лучше его поместить для посылки событий?
Эмпирическим правилом является использование триггеров, когда приложениям нужно знать о событиях на уровне строки - одной строки или множества строк, в зависимости от области действия транзакции, - и процедур для сигнализации о таких событиях, которые воздействуют на приложения в целом.
Это только общие соображения - часто процедуры имеют область действия на уровне строки, и если заинтересованные клиенты хотят знать, когда произошла конкретная операция, событие посылается в такой хранимой процедуре. В этом случае POST_EVENT в триггере не будет иметь возможности ничего сообщить приложениям о контексте события. Разработчик может использовать события в процедуре, чтобы установить, какое приложение ответственно за выполнение соответствующей работы. В другом варианте разработчик может поместить сообщение о событии в триггер, чтобы гарантировать, что конкретное действие DML будет информировать всех, независимо от контекста, в котором оно выполняется.
Теперь мы обратимся к безопасности вашего сетевого окружения СУБД. В этой части мы рассмотрим риски и меры безопасности, связанные с выполнением ваших серверов баз данных Firebird. Для начала в следующей главе обсуждаются некоторые слабые места в системе защиты операционного окружения и меры, которые вы можете принять по их устранению.
ЧАСТЬ VIII. Безопасность.
ГЛАВА 33. Безопасность в операционной среде.
В Firebird не существует средств для шифрования и дешифрования данных (кроме паролей пользователей), которые передаются через клиентский интерфейс. Существуют некоторые ограничения в использовании инструментов Firebird, которые осуществляют доступ к базам данных, но, в конечном счете, на уровне программного обеспечения нет защиты от налетчиков, которые установили доступ к вашей базе данных без авторизации.
В этой главе на первый план выдвигаются некоторые вопросы, по поводу которых вы должны предпринять меры предосторожности в вашем окружении сервера и клиентов Firebird. Не имеет никакого смысла выполнять проектирование для решения всех относящихся к безопасности окружения вопросов, которые могут воздействовать на ваш сервер и вашу сеть. Короче говоря, если безопасность имеет серьезное значение для установки вашей системы, то и отнеситесь к ней серьезно. Исследуйте ее, определите потенциальные зоны рисков и будьте готовы консультироваться со специалистами.
В главах 34 и 35 рассматриваются средства Firebird по управлению доступом на уровнях сервера Firebird и баз данных, соответственно. Глава 36 содержит подробности конфигурирования серверов Firebird для уменьшения незащищенности данных при некоторых рисках для безопасности, связанных с окружающей средой.
Физическая безопасность
Содержите серверы и чувствительные или критичные клиентские машины в помещениях с хорошо закрываемыми дверями. Если у вас на серверах или рабочих станциях установлена система FAT32, любой пользователь, локально подключившийся к одной такой машине, может получить доступ и ко всем другим. Если возможно, заблокируйте такие ресурсы, как CD-ROM, накопители на гибких магнитных дисках и драйверы Zip, отключите порты, через которые можно получить доступ к устройствам первоначальной загрузки или установите такие режимы в BIOS, которые предотвратят загрузку со съемных устройств. Установите в BIOS защиту по паролю, чтобы предотвратить неавторизованные изменения режимов первоначальной загрузки. Установите защиту по паролю на все серверы и рабочие станции.
Основным фактором физической безопасности является защита чувствительных к безопасности машин от физических контактов неавторизованных лиц. Все остальное не даст никаких результатов, если посторонние могут получить доступ к машине и осуществить кражу, или если кто-то может открыть дверь в эту комнату и украсть накопитель на жестком диске, подключенный к серверу.
128
См. APIGuide.pdf в комплекте документации по InterBase, опубликованной Borland Software Inc.
129
He следует путать с компонентами-обработчиками сообщений, которые инкапсулируют на клиентской стороне механизм событий.