! ! !
ПРИМЕЧАНИЕ. Помните, что некоторые продукты Borland жестко запрограммированы на распознавание внутренних версий строк только для Borland. Даже если имя и размещение в файловой системе являются "корректными" для элементов Borland, ограничение строки версии может сделать ваше приложение несовместимым со встроенным сервером. Например, приложения, скомпилированные с использованием оригинальных компонентов InterBaseXpress (IBX), не будут соединяться cfbembed.dll без внесения изменений.
. ! .
Жестко закодированные пути к базе данных
Строка соединения, например, WlNSERVER:C:\Program Files\Firebird\Firebird 1 5 \employee.fdb, жестко закодированная в вашем приложении, явно вызовет проблемы при установке вашего программного обеспечения на другой машине. Ваш код должен адаптироваться к размещению базы данных, что неизвестно во время проектирования и часто ограничено локальным (не localhost) соединением. Это не является проблемой, появившейся в случае со встроенным сервером. Нам часто нужно поставлять наше программное обеспечение приложений клиент/сервер с предоставлением пользователям или системным администраторам возможности конфигурирования размещения баз данных в сети и в файловой системе.
Система алиасов баз данных позволяет вам компилировать приложения с "мягкими" путями файловой системы к базе данных. Каждый раз, когда код приложения ссылается на сегмент пути в строке соединения, то используется алиас, и определение размещения в файловой системе становится задачей поиска установок в aliases.conf.
Предположим, например, что вы решили использовать EMPDATA В качестве алиаса. В файле aliases.conf на вашей машине разработки вы указали для алиаса ваш путь:
EMPDATA = C:\Program Files\Firebird\Firebird_1_5\employee.fdb На другой машине это может быть:
EMPDATA = D:\databases\employee.fdb
Это решает вопрос с сегментом пути и исключает один уровень сложности. Причем у вас еще может остаться проблема с протоколом соединения. Могут потребоваться некоторые изменения, если приложение жестко закодировано на имя хоста и формат строки для соединения TCP/IP или именованных каналов.
Утилиты удаленных сервисов
Утилиты, использующие Services API или старые переключатели менеджера сервисов для удаленного администрирования, должны быть отключены или адаптированы к работе с локальным протоколом. Конкретные меры будут зависеть от того, как реализована ваша архитектура клиент/сервер. Если ваше существующее приложение предоставляет возможности, которые обеспечивают безопасность и стабильность сервера, вам также нужно рассмотреть реализацию обращения приложения к серверу, где по существу обходится идентификация пользователя.
Вопросы безопасности сервера
Любая библиотека встроенного сервера, размещенная на машине, где находится и база данных, потенциально является Троянским конем. На уровне сервера средства безопасности оперируют в предположении, что любой пользователь, соединяющийся с базой данных, будет идентифицироваться через базу данных безопасности security.fdb. Однако, когда встроенный сервер подключает клиента, идентификация пользователя с его паролем пропускается. Поскольку любой пользователь способен соединиться с любой базой данных, безопасность сервера будет легко отменена, если только серверная машина не будет защищена физически.
Можно написать приложение встроенного сервера, которое "соединится как пользователь SYSDBA", используя вообще что угодно в качестве пароля SYSDBA. Не существует никакого способа, чтобы сервер сообщил, что пользователь SYSDBA "прошел через стеклянный потолок" без допустимого пароля. Если SYSDBA активен в любой базе данных, то этот пользователь сможет соединяться и вытворять все, что ему захочется без каких-либо ограничений. Любой, кто имеет доступ к вашей сети и имеет привилегии к файловой системе на сервере, может установить злонамеренное приложение встроенного сервера, которое сможет читать и писать любые данные в ваши базы данных или вовсе их удалить.
Помните, что база данных безопасности (security.fdb) является такой же базой данных, как и другие. Пользователь SYSDBA имеет к ней специальные привилегии SQL - как и ко всем базам данных - для создания, модификации и удаления чего угодно.
Подготовленная машина для баз данных защищена от физических вторжений и неавторизованного доступа к файловой системе, "вошедший" в базу данных пользователь, не являющийся SYSDBA, будет субъектом обычных ограничений привилегий SQL. Привилегии SQL к объектам данных в базах данных Firebird применяются на основе "участия" - никакой пользователь, за исключением SYSDBA и владельца базы данных, не имеет автоматических прав к любым объектам любых баз данных.
Поэтому все еще необходимо предоставить способ для пользователя (или приложения) передавать имя пользователя и, желательно, роль обычной процедуре подключения. Разработчики должны предоставлять и привилегии защиты, и охранную процедуру.
См. главы 34 и 35 по вопросам безопасности доступа к серверу и привилегиям SQL к объектам базы данных.
Совместимость нескольких серверов
Любое количество приложений встроенного сервера может выполняться одновременно без каких бы то ни было конфликтов. Однако невозможно нескольким встроенным серверам иметь одновременный доступ к одной базе данных по причине блокировки, применяемой в архитектуре Суперсервера при первом успешном подключении.
Обычные серверы Firebird и InterBase могут без конфликтов одновременно выполняться на машине, на которой запущены встроенные серверы. Для доступа локального клиента следует обратить внимание на исключение конфликта пространства имен между обычными клиентскими библиотеками (gds32.dll и fbclient.dll) и именем, выбранным для библиотеки встроенного сервера.
"Клиентская" часть fbembed.dll может быть обычным, удаленным клиентом других серверов; в то же самое время она внутренне связывается со своим встроенным сервером.
Останов встроенного сервера
Выполнение встроенного сервера не может быть остановлено кроме как при завершении клиентского приложения. Ваше приложение должно завершаться с обычным завершением транзакций и отключением от всех баз данных.
Модули внешних кодов
Firebird может расширить свои возможности путем доступа к определенным пользователям подпрограммам, написанным на включающем языке программирования и скомпилированным во внешние библиотеки общего доступа. Этот раздел содержит рассмотрение некоторых вопросов и техник, относящихся к написанию внешних функций (UDF) и фильтров BLOB.
* Внешние функции: Firebird "путешествует налегке" в отношении встроенных функций. Вместо того чтобы навешивать на сервер огромную библиотеку скрытых функций, Firebird позволяет разработчикам выбрать - и, при необходимости, определить- их собственные библиотеки внешних функций, которые соответствуют потребностям вычислений и выражений в их базах данных. Функции, определенные пользователем (User-Defined Function, UDF), добавляют высокую гибкость в среду вашей базы данных. UDF являются расширением функций сервера Firebird на серверной стороне; они объявляются для баз данных и выполняются в контексте серверного процесса.
Как и стандартные встроенные функции SQL, UDF могут быть разработаны для выполнения конвертирования данных или для вычислений, которые сложно или вообще невозможно выполнить в языке SQL. UDF включают функции для статистики, строк, дат и математических вычислений.
В разд. "Внешние функции" главы 21 подробно объясняется, как размешать, объявлять и использовать внешние функции, а также как сконфигурировать их размещение в файловой системе, чтобы исключить некоторые риски безопасности и целостности, существующие при выполнении внешнего кода вместе с ядром сервера. Конфигурация по умолчанию и режимы файловой системы также обсуждались ранее в этой главе при рассмотрении параметров udfAccess (версия 1.5) и externaI_fiIe_directory (версия 1,0.x).