This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Переход на базу Дискуссии" Пример 2. Автоматическое возвращение в истории на два шага назад (JavaScript). "<script>history.go(-2);";
Отметим, что эффект, обеспечиваемый полем $$Return, может быть также достигнут "печатью HTML-кода" оператором Print из LotusScript в агенте, запускаемом по событию WebQuerySave (при сохранении).
5.2.8. Доступ к переменным CGI Имеется два способа получения значения CGI-переменной: 1. агентом на LotusScript, запускаемым «из броузера» (по URL типа ?OpenAgent или на события WebQueryOpen или WebQuerySave), с использованием свойства DocumentContext класса NotesSession; 2. созданием вычисляемого поля типа text с именем, совпадающим с именем нужной CGIпеременной, и именем этой переменной в качестве формулы. Однако для агентов, запускаемых на события WebQueryOpen или WebQuerySave, надежно работает только сочетание обоих способов: в документе должны присутствовать поля, имена которых совпадают с именами требуемых CGI-переменных, тогда с помощью агента на LotusScript можно работать с их значениями. Сказать точнее, автору известен единственный случай, когда в агенте, запускаемом на событие WebQueryOpen, удалось получить значение CGI-переменной Query_String, не имея в форме поля Query_String. Пример 1. Получение значения CGI-переменной REMOTE_USER и занесение ее значения в поле Effect агентом, запускаемым на событие WebQueryOpen (поле remote_user должно присутствовать в документе): Dim sess As New notessession Dim doc As notesdocument Set doc = sess.DocumentContext Dim remote As Variant remote = doc.remote_user(0) Call doc.ReplaceItemValue("Effect", remote) Call doc.Save(True, False)
Если Вы хотите только сохранить значение CGI-переменной в документе, не оперируя с ним (значением) до трансляции документа в HTML, то это можно сделать, создав поле с именем, совпадающим с именем нужной переменной (способ 2), например REMOTE_USER типа text/Computed со значением REMOTE_USER. Cписок CGI-переменных приведен в разделе 3.3.2. Пример 2. Агент на LotusScript (из журнала THE VIEW), который выводит все доступные во время его запуска CGI-переменные. Sub Initialize Dim sess As New NotesSession Set doc = sess.DocumentContext
© InterTrust Co. Тел. 956-7928
54
Разработка форм для Web-приложений Domino
Print "Display context variables
" Forall item In doc.items Print "
" & item.Name & ":" If Isempty(item.Text) Then Print "EMPTY" Else Print item.Text End If End Forall End Sub Результат его работы приводится на следующем рисунке.
Рис. 5.8 Результат работы агента, выводящего все доступные CGI-переменные.
5.2.9. События WebQueryOpen и WebQuerySave WebQueryOpen и WebQuerySave - единственные события, которые происходят в форме при работе из Web-броузера.
WebQueryOpen По умолчанию имеет значение @Command([ToolsRunMacro]; ""). В этом событии указывается один или несколько агентов, которые выполняются до того, как документ будет преобразован в HTML и отправлен в броузер. Изменения, вносимые в документ агентами на @формулах, не отображаются при первом открытии HTML-страницы, так как документ изменяется на сервере уже после того, как его HTML-версия была передана броузеру. Для того, чтобы произвести изменения в документе до его трансляции в HTML и передачи броузеру, нужно в агенте, написанном на LotusScript, воспользоваться свойством DocumentContext класса NotesSession. В Notes версии 4.5 вместо данного события использовалось специальное текстовое поле $$QueryOpenAgent. В качестве его значения указывается имя (одного) агента. В Notes версии 4.6 содержимое поля $$QueryOpenAgent игнорируется, если какие-то агенты указаны в событии WebQueryOpen. С помощью агента на LotusScript можно сформировать страницу для конкретного пользователя (или в зависимости от других доступных CGI-переменных), но при этом важно учесть, что для использования CGI-переменной в документе должно присутствовать поле с
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 55
совпадающим с ней именем. Агент же должен иметь установки Run Manually From Actions Menu и Run once. Domino игнорирует вывод (Print), совершаемый агентом, запускаемым по событию WebQueryOpen. Пример. Увеличение счетчика обращений к документу (counter) на 1 и запись в поле Effect значения CGI-переменной REMOTE_USER. Поле remote_user должно присутствовать в документе. Sub Initialize Dim sess As New notessession Dim doc As notesdocument Set doc = sess.DocumentContext Dim remote As Variant Dim c As Variant, d As Variant remote = doc.remote_user(0) c = doc.counter(0) d = c+1 Call doc.ReplaceItemValue("Effect", remote) Call doc.ReplaceItemValue("counter", d) Call doc.Save(True, False) End Sub
WebQuerySave По умолчанию имеет значение @Command([ToolsRunMacro]; ""). В этом событии указывается агент, который выполняются перед тем, как документ будет сохранен в базе. Впрочем, документ может и не быть сохранен, если в нем присутствует поле SaveOptions со значением "0". В версии Notes 4.5 вместо данного события использовалось специальное текстовое поле $$QuerySaveAgent, а в качестве его значения указывалось имя агента. Примером использования такого агента могло бы быть создание других документов на основе информации из данного. Кроме того, такой агент может использоваться вместо поля $$Return для формирования подтверждающего HTML-сообщения - оно создается с помощью операций Print на LotusScript.
5.2.10. Computed Text Computed Text (вычисляемый текст) - новая возможность Notes версии 4.6, позволяющая вычислять по @-формуле фрагменты статического текста в форме и фрагменты текста в полях типа Rich Text. Использование Computed Text как вычисляемого статического текста в форме эквивалентно использованию полей типа Computed for display. Однако Computed Text в форме удобно использовать для вставки HTML-кода (как текст, «заключенный в квадратные скобки» или «написанный» стилем HTML). При использовании Computed Text в поле типа Rich Text его формулу после создания можно вновь отредактировать, выбрав в меню Hotspot/Edit Hotspot, а также можно изменить внешние атрибуты: тип рамки вокруг текста и его параметры (шрифт, выравнивание и т.д.). Вероятно, основное «достижение» Computed Text в полях типа Rich Text состоит в том, что пользователь, имеющий к базе уровень доступа ниже Designer, может «придать тексту некоторую вычисляемость», используя формулы наподобие "Hello "+@UserName.
© InterTrust Co. Тел. 956-7928
56
Разработка форм для Web-приложений Domino
5.2.11. $$-поля В Domino существует ряд специальных «двухдолларовых» полей, предназначенных для выполнения функций, присущих только Web-приложениям. Обычно для этих полей используется тип Text/Computed for display.
$$ViewBody На месте этого поля в форме отображается вид или папка, имя которой указанно в значении поля. В версии 4.6 аналогичного результата можно достичь, используя команду меню Create/Web element/Embedded View.
$$ViewList На месте этого поля в форме отображается стандартный навигатор folders. Значение поля игнорируется. В версии 4.6 аналогичного результата можно достичь, используя команду меню Create/Web element/Embedded Folders Pane.
$$NavigatorBody, $$NavigatorBody_n В качестве значения поля указывается имя навигатора или формула, вычисляющая имя навигатора. На месте этого поля в форме отображается соответствующий навигатор. В документе может быть несколько таких полей, различающихся только числом n. В версии 4.6 аналогичного результата можно достичь, используя команду меню Create/Web element/Embedded Navigator.
$$Return Используется для замены стандартного подтверждающего сообщения, возникающего после нажатия на кнопку Submit. В этом поле может быть задан HTML-код или формула для его вычисления. Если в качестве значения поля «написать URL в квадратных скобках», то этот URL будет открываться немедленно после нажатия на Submit. Отметим, что эффект, обеспечиваемый полем $$Return, может быть также достигнут из LotusScript «печатью HTML-кода» оператором Print в агенте, запускаемом на событие WebQuerySave.
$$HTMLHead В этом поле задается HTML-код или формула для его вычисления, добавляемый в тег Head. В поле обычно указывается мета-информация, например: <META NAME="Author" CONTENT="Sergei V. Budylov"> <META NAME="description" CONTENT="InterTrust Corp. is DB developer under Lotus Notes."> <META NAME="keywords" CONTENT="InterTrust, Lotus, Notes, Domino, Database, developer, reseller, distributor">
Может также даваться изображение для фона страницы () и определение основного окна вывода ().
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 57
$$QueryOpenAgent В качестве значения поля указывается имя агента (в кавычках), который запускается перед открытием документа. Domino игнорирует вывод, генерируемый при этом агентом. В версии 4.6 для этих целей существует событие WebQueryOpen, в котором по умолчанию указана следующая формула: @Command([ToolsRunMacro]; ""). Имя агента задается вместо .
$$QuerySaveAgent В качестве значения указывается имя агента (в кавычках) который запускается «после нажатия кнопки Submit»: после проверки полей (validation), но перед сохранением документа. В версии 4.6 для этих целей существует событие WebQuerySave, в котором по умолчанию указана следующая формула: @Command([ToolsRunMacro]; ""). Имя агента задается вместо .
5.2.12. Способы внедрения HTML в конструкции Notes В продвинутых Web-приложениях в элементы дизайна Notes часто «напрямую» включают HTML-код. Чаще всего это делается для вставки графических изображений в формы, документы и виды, а также для конструирования страниц с фреймами.
Заключение HTML-кода в квадратные скобки Это наиболее удобный способ для вставки короткого HTML-кода. Он позволяет размещать в одной строке объекты Notes и код HTML. Пример 1. Указание размеров редактируемых полей. Код вставляется в Help description в свойствах поля на закладке Options. Пример 2. Для полей типа text (размер поля для ввода / максимальная длина вводимой строки). [<size=30 maxlenght=40>] Пример 3. Для полей типа keywords (число видимых одновременно вариантов выбора). [<size=5>] Пример 4. Для полей типа Rich Text (размеры поля для ввода / способ переноса строк). [] Пример 5. Ссылка на графический файл. [] Пример 6. Горизонтальная линия. [] Пример 7. Сочетание текста и HTML в одной строке. [] Bold text here [] Пример 8. Создание hotspot'ов «вокруг» кода HTML. Это может быть необходимо, например, при замене стандартных акций для управления видом. URL для них вычисляется динамически, поэтому нельзя использовать предопределенные [...]. []
© InterTrust Co. Тел. 956-7928
58
Разработка форм для Web-приложений Domino
Назначение абзацу стиля HTML Можно создать стиль текста с зарезервированным названием HTML. Абзацы, «написанные этим стилем», будут без интерпретации вставляться Domino в генерируемый HTML-код.
Назначение абзацу атрибута Pass-Thru HTML Абзацы с таким атрибутом будут без интерпретации вставляться Domino в генерируемый HTML-код. По сравнению с предыдущим способом основное неудобство данного заключается в том, что стиль текста «виден» в строке статуса, а чтобы «посмотреть», установлен ли атрибут Pass-Thru HTML, нужно открыть пункт меню Text.
Поле с именем HTML Если в документе присутствует поле с именем HTML, Domino передает в броузер только содержащийся в нем текст - все остальное игнорируется.
Включение в свойствах формы флага Treat document contents as HTML Во многом аналогично использованию поля HTML. Весь видимый текст из документа без обработки передается броузеру как HTML-код. Аналогичное свойство имеется для видов.
Поле $$HTMLHead Содержимое поля передается в броузер как HTML-код между тегами и .
Событие HTML Attributes Позволяет добавить HTML-аттрибуты в некоторые теги. Рассматривалось в разделе 5.2.5.
5.3.
Web-элементы для форм 5.3.1. Embedded Navigator
Embedded Navigator - навигатор Notes, встроенный в форму. Он создается командой меню Create/Web element/Embedded Navigator. В одну форму можно вставить несколько навигаторов, в том числе вычисляемых по @-формуле. В Notes версии 4.5 подобное было реализовано с помощью специальных полей $$NavigatorBody и $$NavigatorBody_n. В качестве значения поля указывается имя навигатора или @-формула, вычисляющая имя навигатора. На месте такого поля в форме отображался соответствующий навигатор. В документе можно быть создано несколько таких полей, различающихся только числом n. Такой способ тоже работает и в версии 4.6.
5.3.2. Embedded View Embedded View - вид Notes, встроенный в форму. Создается командой меню Create/Web element/Embedded View. В форме может быть только один Embedded View, содержащий вид, имя которого задано явно или вычислено по @-формуле. В Notes версии 4.5 для достижения подобного использовалось поле $$ViewBody. В качестве значения поля указывалось имя вида или @-формула, вычисляющая имя вида. На месте этого поля в форме отображался соответствующий вид. В версии 4.6 этот способ тоже работает.
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 59
5.3.3. Embedded Folder Pane Embedded Folder Pane - стандартный навигатор Folders, встроенный в форму. Создается командой меню Create/Web element/Embedded Folder Pane. В форме может быть только один Embedded Folder Pane. В Notes версии 4.5 для этих целей использовалось поле $$ViewList, на месте которого отображался навигатор Folders. В 4.6 этот способ тоже работает.
5.3.4. File Upload Control File Upload Control - элемент для присоединения файлов к документу в базе Notes из броузера. Для того, чтобы создать такой элемент, нужно выбрать из меню Create/Web Element/File Upload Control. В Notes версии 4.5 аналогичный результат достигался путем создания Action Hotspot с формулой @Command([EditInsertFileAttachment]). Для File Upload Control Domino генерирует тег , например:
В броузере элемент выглядит как поле с кнопкой Browse. В этом поле пользователь броузера выбирает или вводит путь к файлу. Чтобы удалить присоединенный файл из документа в базе Notes, используя броузер, нужно в режиме редактирования пометить его для удаления и сохранить документ.
5.4.
Формы-шаблоны
5.4.1. Формы-шаблоны для видов Такие формы должны иметь имена $$ViewTemplateDefault или "$$ViewTemplate for viewname", где viewname - имя вида. В каждой форме необходимо поле $$ViewBody. Наличие формы "$$ViewTemplate for viewname" перекрывает использование $$ViewTemplateDefault для вида viewname. Соответствующая форма будет открываться при обращении из броузера к виду данной базы, а тело вида будет отображаться на месте поля $$ViewBody. Используется этот прием в основном для замещения стандартных акций, которые Domino генерирует по умолчанию, а также для отображения на одной странице дополнительных навигаторов и ссылок. Применяя такую форму, удобно задать и фоновое изображение для вида. Заметим, что последнее можно достичь и «приписаванием» к названию вида текста наподобие [], но это «будет заметно» в Notes.
5.4.2. Формы-шаблоны для навигаторов Такие формы должны иметь имена $$NavigatorTemplateDefault или "$$NavigatorTemplate for navname", где navname - имя навигатора. В каждой форме необходимо поле $$NavigatorBody. Наличие формы "$$NavigatorTemplate for navname" перекрывает использование $$NavigatorTemplateDefault для навигатора navname. Соответствующая форма открывается при обращении к навигатору navname, а навигатор отображается на месте поля $$NavigatorBody. Формы-шаблоны для навигаторов обычно используются для отображения на одной странице вида и дополнительных ссылок.
5.4.3. Формы-шаблоны для поиска Форма с именем $$Search заменяет стандартную форму для формирования поисковых запросов по базе (search.htm). Использование «своей» поисковой формы может оказаться © InterTrust Co. Тел. 956-7928
60
Разработка форм для Web-приложений Domino
неудобным в базе, в которой незарегистрированный пользователь не имеет права создавать документы. Форма с именем $$SearchTemplateDefault или "$$SearchTemplate for viewname", где viewname - имя вида, применяется для изменения способа оформления результатов поиска. В форме необходимо наличие поля $$ViewBody. По сравнению со страницей, которая генерируется по умолчанию, у такой не будет показываться количество найденных документов и текст запроса, а так же будет отсутствовать конструктор уточняющего запроса. Форма с именем $$SearchSiteTemplate используется для изменения способа оформления результатов поиска в базе SearchSite. По сравнению со страницей, которая генерируется по умолчанию, у такой не будет показываться количество найденных документов и текст запроса, а так же будет отсутствовать конструктор уточняющего запроса.
5.4.4. Формы-шаблоны обработки ошибок в Domino Для оформления сообщений об ошибках в конкретной базе в соответствии с необходимым вам стилем применяются формы со следующими зарезервированными названиями.
• • • •
$$ReturnDocumentDeleted - подтверждение успешного удаления документа. $$ReturnAuthenticationFailure - сообщение о том, что такой пользователь с таким паролем не зарегистрирован на сайте. $$ReturnAuthorizationFailure - сообщение о том, что данный пользователь не имеет достаточно прав для выполнения данной операции. $$ReturnGeneralError - выдается на любую другую ошибку.
Однако следует земетить, что замена стандартных сообщений об ошибках часто делает эти сообщения менее информативными. Например, для следующей ошибки Error 500 HTTP Web Server: Lotus Notes Exception - Special database object cannot be located
будет известно только то, что она относится к типу General Error.
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 61
6. Разработка видов, навигаторов и карт-изображений для Web-приложений Domino 6.1.
Виды
Domino транслирует для броузера вид Notes в таблицу HTML, по умолчанию не более чем из 30 строк. Такое «количество строк по умолчанию» задается в общей адресной книге в документе Server в секции HTTP Server, в поле Lines per view page. Для конкретного URL, указывающего на вид, максимальное количество строк таблицы задается параметром Count в самом URL. Стандартные кнопки позволяют "пролистывать" вид в обоих направлениях, раскрывать/сворачивать все категории и создавать поисковый запрос для полнотекстового поиска по данной базе. Для стандартных операций со видом используются следующие формулы: пролистнуть вперед - @DbCommand("Domino";"ViewNextPage"); пролистнуть назад - @DbCommand("Domino";"ViewPreviousPage"); раскрыть все категории - @Command([ViewExpandAll]); свернуть все категории - @Command([ViewCollapseAll]); поиск - @Command([ViewShowSearhBar]). Следует отметить, что содержимое колонки с ответными документами (с «включенной» опцией Show responses only) отображается в том же столбце таблицы, в которую Domino преобразовал вид, что и следующая видимая колонка вида. При этом, несмотря на то, что на каждый ответный документ в виде выделяется отдельная строка, Domino не использует для HTML-аналога этой строки параметр colspan для объединения столбцов. В результате текст, соответствующий в виде ответному документу, может располагаться «в несколько строк узким столбцом», несмотря на то, что справа от него может быть свободное место. Бороться с таким эффектом можно путем размещения в виде сразу за колонкой с ответными документами одной широкой колонки, которая была бы последней видимой колонкой в виде.
6.2.
Навигаторы и карты-изображения
Карты-изображения (Image Map) позволяют получить эффектный (в смысле внешнего вида) набор гипертекстовых ссылок. Суть в том, что на одном графическом изображении выделяются несколько активных зон, каждая из которых является гипертекстовой ссылкой. Преимущество карты-изображения состоит в том, что один «большой» файл «скачивается» значительно быстрее, чем несколько «маленьких» с таким же суммарным размером. Недостатком карты-изображения для разработчика в первую очередь является неудобство внесения изменений в единый графический файл вместо замены «одного маленького». Использование векторно-объектной графики навигаторов Notes теоретически снимает эту проблему. Но поскольку редактор, используемый в Notes для создания навигаторов, достаточно примитивен, его возможностей может не хватить для создания чего-то «действительно красивого». А если вы хотите сделать так, чтобы графические кнопки «подсвечивались» при наведении на них курсора мыши, то и Image Map вам уже не подойдет. Недостатком карты-изображения для пользователя является невозможность воспользоваться ее встроенными ссылками до того, как изображение полностью загрузится в броузер. Кроме того, альтернативный текст для Image Map броузеры MSIE 3.02 и 4.0 не
© InterTrust Co. Тел. 956-7928
62
Разработка видов, навигаторов и карт-изображений для Web-приложений Domino
показывают вообще, а Netscape Communicator 4.04 показывает только при наведении курсора мыши на ссылку. Примером хорошего применения карты-изображения может быть интерактивная карта города, из которой можно открывать карты районов, «кликая» на них мышью. Генерируя HTML, Domino преобразует навигаторы Notes в карты-изображения, но при этом имеются три недостатка. 1. При обращении к навигатору некоторое время расходуется на преобразование его объектно-векторной графики в растровое изображение. 2. Если в используемом изображении больше 16 цветов, его палитра может заметно изменится при просмотре в броузере. Кроме того, «не сглаживается» текст (вероятно, ради быстроты преобразования) и не поддерживается анимация GIF89a. 3. В свойствах активной области навигатора нельзя указать для нее альтернативный текст. Если навигатор Notes имеет небольшие размеры и точная цветопередача вам не критична, навигатор можно рекомендовать к использованию. В том же случае, когда недостатки применения навигатора существенны, вам придется создать необходимый графический файл и фрагмент HTML-кода для карты-изображения. При подготовке HTML-кода для карты-изображения вам может сослужить «добрую службу» редактор, используемый в Notes для создания навигаторов. Технология такова. 1. Подготовленное изображение поместите в Graphic Background навигатора (можно с помощью File/Import). 2. Поверх изображения «расставьте» нужные активные области (hotspot'ы). 3. Выберите для hotspot'ов в качестве действия Simple action(s)/Open URL и укажите нужный URL. Если URL пока не неизвестен, вместо него можно указать любой идентификатор, позволяющий Вам опознать эту ссылку в HTML-коде и впоследствии заменить нужным URL. 4. Открыв после всего этого навигатор в броузере, остается получить и сохранить HTMLкод этой страницы. В нем будет присутствовать необходимый Image Map. Так значительно быстрее, чем «вручную вбивать» координаты областей в HTML-код. Остается привести пример HTML-кода для карты-изображения. <MAP NAME="main.map">
Выглядит же эта карта-изображение в броуэере следующим образом (фрейм слева).
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 63
Рис. 6.1 Набор ссылок, организованный в Image map (фрейм слева) Отметим, что в Notes версий 4.5 многие элементы навигаторов не работали в при просмотре броузером, а наличие у навигатора Graphic Background было для Domino обязательным.
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 65
7. Разработка агентов для Web-приложений Domino В Notes агенты используются для автоматизации выполнения многих задач, например создания документов, отправки почты, поиска, архивирования устаревших документов. Существует несколько способов активации (запуска) агентов: по расписанию, при «вставке» документов в базу из буфера обмена, при поступлении новой почты, при создании или модификации документов. Пользователь может также запустить агента, «кликнув» мышкой на кнопке, hotspot’у или акции формы или вида с формулой @Command([ToolsRunMacro]) или URL с операцией ?OpenAgent. Однако агенты Notes обычно ориентированы больше на работу с ними с клиентского места Notes, чем из Web-броузера. Поэтому для выполнения одной и той же задачи как из клиента Notes, так и из броузера, чаще приходится использовать два набора агентов, каждый из которых специализирован для одного интерфейса. Основная причина такого разделения - различия в способах взаимодействия агента с пользователем в разных средах. В Notes агент может запрашивать и получать информацию от пользователя в различных диалоговых окнах и изменять значения полей непосредственно в открытом в клиенте Notes документе. Единственный же способ передать информацию клиенту броузера (без применения JavaScript) создать и загрузить в броузер HTML-страницу. При этом разработчик Web-приложения может внести агентом изменения в текущий документ или перед тем, как по этому документу сервером будет сгенерирован и передан в броузер HTML-код (агент на событие WebQueryOpen), или после того, как данные HTML-формы будут переданы из броузера на сервер, но перед тем, как документ будет сохранен сервером (агент на событие WebQuerySave). Агенты для пользователей Web чаще всего пишутся на LotusScript или Java, поскольку «простые действия» Notes недоступны в Web-приложениях, а @-формулы не позволяют возвращать информацию пользователю.
7.1.
Агенты с опцией Run agent as Web User
Notes всегда осуществляет контроль прав доступа запускаемого и выполняемого агента. Агент, запускаемый пользователем Notes «вручную», имеет такие же права доступа, как и запустивший его пользователь. Права агента, выполняемого сервером по расписанию или событию, определяются правами создателя или последнего редактора этого агента (того, кем подписан агент). Один из вариантов агентов, доступных пользователям Web-броузеров - агенты с опцией Run agent as Web User.
Рис. 7.1 Свойства агента. Закладка Design
© InterTrust Co. Тел. 956-7928
66
Разработка агентов для Web-приложений Domino
Чтобы такой агент мог быть запущен сервером, создатель или последний редактор агента (тот, кем агент подписан) должен иметь на сервере права на выполнение агентов. Хотя пользователи броузеров не имеют ID-файлов, Domino способен аутентифицировать их. Поэтому при выполнении такой агент обладает правами не его создателя, а запустившего его пользователя броузера.
7.2.
Агенты - аналоги программ CGI
Поведение агента, запускаемого на сервере Domino из web-броузера, очень похоже на поведение CGI-програмы, запускаемой на «обычном» HTTP-сервере. Во-первых, такие агенты могут «печатать» операторами Print языка LotusScript HTML-код, который по завершении работы агента передается броузеру. Если же операторов Print в агенте нет, по окончании его работы в броузер посылается «подтверждающее сообщение» Agent done. Во-вторых, агентам, запускаемым из броузера, доступны переменные CGI. В данном разделе мы рассмотрим только агенты, запускаемые на сервере Domino из броузера «вручную» по команде @Command([ToolsRunMacro]) или по URL с операцией ?OpenAgent. Агенты, запускаемые по событиям WebQueryOpen и WebQuerySave будут рассмотрены в следуюших разделах главы. Пример 1. Агент AddBook, создающий по информации из CGI-переменных вспомогательный документ в базе и посылающий в броузер подтверждающее сообщение. Агент запускается по вычисляемому в hotspot’е URL наподобие http://host/DbName/AddBook?OpenAgent&UNID, где параметр UNID задает универсальный идентификатор документа, из которого запущен агент. Sub Initialize Dim sess As New NotesSession Dim doc,element As NotesDocument Dim dateTime As NotesDateTime Dim db As NotesDatabase Dim c,c1,d As Variant Set db=sess.CurrentDatabase Set dateTime = New NotesDateTime( "Today" ) Set element=New NotesDocument( db ) Set doc = sess.DocumentContext ‘Получение строки запроса (в данном случае вида ?OpenAgent&UNID) c = doc.Query_String(0) ‘Получение UNID документа из строки запроса c1 = Right(c, 32) ‘Получение IP-адреса пользователя d = doc.Remote_Addr(0) ‘Формирование полей документа и его сохранение Call element.ReplaceItemValue("Date", dateTime) element.UNID = c1 element.IP = d element.Form = "Element" Call element.Save(True, False) ‘Выдача подтверждающего сообщения в броузер Print "Книга добавлена в корзину
" Print c1 Print "" Print d End Sub Пример 2. Агент для обработки данных, получаемых из формы методами POST и GET. HTML-код формы, использующейся для сбора информации. © InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 67 test page - post and get methods <SCRIPT LANGUAGE="JavaScript">
Агент WebQR получает информацию из формы и отправляет в броузер подтверждающее сообщение о полученной информации. Sub Initialize Dim s As New NotesSession Dim db As NotesDatabase Set db = s.CurrentDatabase Dim note As NotesDocument Set note = s.DocumentContext Dim RM As String Dim QS,QSD As String Dim CT As String Dim RC, RCD As String RM = note.Request_Method(0) Print "
Request_Method="+RM+"" If ( 0 = Strcompare(RM, "GET", 1) ) Then ' Метод GET - аргументы в Query_String QS = note.Query_String(0) QSD = decode((QS)) Print "
Query_String="+QS+"" Print "
Decoded Query_String="+QSD+"" End If If ( 0 = Strcompare(RM, "POST", 1) ) Then ' Метод POST - аргументы в Query_String и REQUEST_CONTENT QS = note.Query_String(0)
© InterTrust Co. Тел. 956-7928
68
Разработка агентов для Web-приложений Domino
QSD = decode((QS)) Print "
Query_String="+QS+"" Print "
Decoded Query_String="+QSD+"" CT = note.Content_Type(0) Print "
Content_Type="+CT+"" RC = note.Request_Content(0) RCD = decode((RC)) Print "
Request_Content="+RC+"" Print "
Decoded Request_Content="+RCD+"" End If End Sub Функция decode, обрабатывающая получаемые строки. Function decode(content As String) As String ' Декодирование "URL-encoded" строки Dim answer, achar, hexdigits As String Dim pos, max, charval As Integer On Error Goto errhandle max = Len(content) pos = 1 answer = "" While ( pos history.go(-2);";
Форма response очень похожа на форму document. Самое важное отличие - тип формы Response to response. Для большей наглядности привязки в форме response хорошо наследовать
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 89
в специальное поле заголовок родительского документа. Ссылку на родительский документ можно сделать, создав поле типа text/computed со значением $Ref. В этом случае после сохранения в документе появится «линк на родителя». На следующем рисунке показан ответный документ, открытый на редактирование. Внизу виден элемент File Upload.
Рис. 8.9 Редактирование ответного документа в базе «Дискуссии»
8.3.7. Прайс-листы Каталог товаров не всегда удобно использовать в качестве прайс-листа, поскольку каждому товару в каталоге соответствует отдельный документ с его описанием. Цены же на некоторые классы товаров (например, гвозди) могут быть стандартными. В этом случае, по-видимому, следует создать таблицу с ценами на целый класс товаров внутри одного документа. Это можно реализовать в виде отдельной базы по образцу «Новости» или папки (folder) в той же базе, помещая в папку документы, имеющие отношение к прайс-листам.
8.3.8. «Работа» Обычно зона «Работа» создается фирмой для публикации имеющихся вакансий. Если создается крупный сайт, можно также создать базу типа «Биржа труда», в которой web-клиенты смогут создавать как документы типа «вакансия», так и документы типа «ищу работу». Эта база, скорее всего, будет очень похожа на «Каталог с возможностью оставлять заявки».
8.3.9. Регистрация Существует по крайней мере два способа регистрировать web-пользователей на сервере. 1. Администратор сам создает документы Person для пользователей в общей адресной книге (например, на основании запросов, поступающих к нему по электронной почте). 2. Online-регистрация: пользователь сам заполняет регистрационную форму, а данные из формы затем используются агентом для создания соответствующего документа Person в общей адресной книге. Второй способ позволяет пользователю зарегистрироваться намного быстрее, чем первый, а так как для создания документов в базе типа «Дискуссии» требуется, чтобы пользователь был
© InterTrust Co. Тел. 956-7928
90
Создание сайта на основе Lotus Domino
зарегистрирован на сайте, то чем проще и быстрее регистрация, тем вероятнее, что пользователь «не поленится» зарегистрироваться и примет участие в дискуссии. В комплекте с Domino версии 4.6 поставляется пример такой базы для регистрации пользователей под названием Domino 4.6 Samples: Registration. Имеет смысл сохранить в неприкосновенности исходную базу, создав ее новую копию в каталоге Site с названием regzone.nsf, и выполнив доработки, уже рассмотренные нами в разделе 8.1.2.
8.3.10. Полнотекстовый поиск В Domino существует возможность производить полнотекстовый поиск по определенному виду в базе или по нескольким базам. Поиск документов можно производить по отдельным словам, содержащимся в них, или по значениям конкретных полей. ASCII-текст, содержащийся в присоединенных файлах, также может быть проиндексирован. Можно порекомендовать сделать «кнопку» для создания поискового запроса для поиска по всем информационным базам на сайте. «Кнопки» же для создания поискового запроса по конкретному виду входят «в стандартную поставку» к каждому виду. Для того, чтобы реализовать на сайте поиск по нескольким базам, создадим по шаблону Search Site в каталоге Site базу данных, и в ней документ Search Scope Configuration. В таком документе указывается «область» для поиска баз, которые должны быть включены в Multi Database Index или отдельная база. В простом случае достаточно одного документа Search Scope Configuration со следующими значениями полей:
• • • •
Scope - directory («область» для поиска баз - каталог); Server - serg/itsertifier (полное имя сервера Notes); Directory - Site (каталог, в котором находятся нужные базы); Full Text Index Options - Index Full Document (опция индексирования - индексировать весь документ).
У баз, информация из которых будет включаться в Multi Database Index, на закладке Design в свойствах базы должна быть выбрана опция Include in multi database index. Перед тем, как начинать поиск с использованием этой базы, для нее нужно создать полнотекстовый индекс. В руководстве по Domino настоятельно рекомендуется после любого изменения конфигурации этой базы (документов Search Scope Configuration) удалять индекс и создавать заново. Поскольку распространено мнение, что в формах поисковых запросов на русском сайте вспомогательный текст тоже должен быть русским, рассмотрим способы изменения внешнего облика поисковых форм. По умолчанию по команде @Command([ViewShowSearchBar]) открывается файл search.htm из каталога domino\icons. Этот способ хорош тем, что даже пользователь, имеющий к базе доступ Reader, сможет пользоваться этой поисковой формой для составления запроса, ибо создания документа в базе при этом не происходит. Для замены поисковой формы в пределах одной базы создается форма с именем или алиасом $$Search. Лучше всего «позаимствовать» профессионально выполненные формы Web Search Simple и Web Search Advanced из базы Search Site и затем подкорректировать их. Особое внимание следует уделить формуле в поле $$Return. Так как форма была предназначена для поиска по базе Search Site, эта формула имеет примерно следующий вид: DBName:=@Subset(@DbName;-1); "[[/"+DBName+"?SearchSite&Query="+Query+"&Search...
Для поиска в базе по виду формируемый URL следует подправить: "[[/"+DBName+"/ViewName/?SearchView&Query="+Query+"&Search...,
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 91
где ViewName - имя вида, по которому будет производится поиск. Однако тогда, уже по команде @Command([ViewShowSearchBar]), будет создаваться документ, и если пользователь имеет к базе доступ Reader, то Domino запросит его имя и пароль, так как доступа читателя недостаточно для создания документов. Такое поведение особенно неприятно для баз типа «Новости», в которых web-клиенты не должны иметь возможности создавать документы. Однако эту проблему можно решить, указав для «содержательных» форм в свойствах на закладке Access список пользователей, которые могут создавать документы с помощью этих форм, а доступ к базе для web-пользователей «поставить» как Author. Радикальным способом является редактирование упоминавшегося ранее файла search.htm, но перед этим надо убедиться, что старая поисковая форма никому не понадобится. Другой способ заключается в том, чтобы создавать форму для поискового запроса (назовем ее RemoteSearch) в другой базе, в которой web-клиент имеет по умолчанию доступ Author. Задача поисковой формы - упростить формирование URL поискового запроса. Этот URL помещается в поле $$Return (text/computed) в двойных квадратных скобках. URL запроса в общем случае имеет вид: http://Host/NotesDatabase/View/?SearchView&Arguments. Возникает естественное желание использовать одну универсальную поисковую форму и передавать ей в качестве параметров для поиска имя базы и вида. Попытки реализации этого плана часто наводили автора на мысль о простоте редактирования файла search.htm, но тем не менее и без этого удалось добиться некоторых результатов. Как уже говорилось, в базе, в которой Anonymous имеет доступ Author с возможностью создавать документы, создадим форму на основе Web Search Simple и назовем ее RemoteSearch. Добавим поле «для захвата аргументов» с зарезервированным названием Query_String типа text/editable. Аргументы будут передаваться вместе с URL, открывающим поисковую форму, который формируется формулой (для базы news.nsf): @URLOpen("/site/homepage.nsf/RemoteSearch?OpenForm&"+ @ViewTitle+"&news.nsf")
Первый аргумент - имя вида (возвращается как UNID), а второй - файл базы. Часть формулы из поля $$Return в форме RemoteSearch: "[["+"/site/"+@Right(@Right(Query_String;"&" );"&")+"/"+@Left(@Right(Query_String;"&" );"&")+"/?SearchView&Query=... "
Самое интересное здесь в том, что поле $$Return получало информацию из поля Query_String только в том случае, когда последнее не было скрыто, то есть присутствовало в форме, и в него можно было при желании что-нибудь ввести. Все это создавало впечатление некоторой «недоделанности» формы, а потому вряд ли можно было рекомендовать оставить все в таком виде. Менее красивый, но более надежный путь - отказаться от передачи параметров и создать для каждого вида, в котором нужно искать, свою форму типа RemoteSearch, где в поле $$Return прямо указать файл базы и вид, например: "[[/site/news.nsf/ByTopic/?SearchView&Query=... "
Если учесть, что обычно требуется поиск только по одному специально для этого предназначенному виду для каждой базы, то работы будет не так уж много. И последнее из того, что автор хотел сказать о поисковых запросах - возможность поиска по значениям полей. Поисковый URL выглядит в этом случае примерно так: http://serg/site/news.nsf/ByAuthor/?SearchView&Query=FIELD+Creator=Sergei+B udylov+AND+FIELD+Form=document+AND+FIELD+DateModifyed>=15.01.98
© InterTrust Co. Тел. 956-7928
92
Создание сайта на основе Lotus Domino
Существует также возможность изменять оформление списка результатов поиска путем создания формы с названием $$SearchTemplate for viewname или $$SearchTemplateDefault. В обоих формах должно присутствовать поле $$ViewBody (его значение игнорируется), которое по сути только обозначает место, где в форме будет расположен список результатов. Для базы типа Search Site такая форма будет называться $$SearchSiteTemplate. Рекомендуется использовать эту возможность только в том случае, если пользователи «чрезвычайно плохо» относятся к английскому тексту. Дело в том, что при использовании этих форм имеются две «неприятности»: 1) пропадает заголовок результатов, содержащий запрос и число найденных документов; 2) пропадает поле для ввода уточняющего поискового запроса.
8.4.
Развитие и обслуживание сайта
Взявшись однажды за разработку сайта, остановиться уже практически невозможно. С каждым днем растет число людей, желающих получать нужную для себя информацию с сайта. Информация должна часто обновляться и всегда быть актуальной. Чем более эффективно размещение информации на сайте, тем больше различной информации о компании хочется «туда выложить», а это неминуемо приведет к появлению новых зон. Прежде всего может появиться потребность создать зону линков на другие сайты. Держать несколько лишних картинок на home page «накладно» - они замедляют открытие страницы. Скорее всего, это будут линки на компании-партнеры (с которыми всегда полезно обменяться линками), а также на крупные компании-поставщики продукции. Использование электронной почты часто может оказаться более эффективным, чем телефонный звонок в компанию. Страница или зона (в зависимости от количества информации) «Контактные лица компании», на которой перечислены соответствующие сотрудники с описанием, какими вопросами они занимаются и указаны их адреса е-mail, поможет пользователю точно адресовать вопрос и получить обдуманный и компетентный ответ. Действительно, такой способ не вынуждает сотрудника компании что-то «лихорадочно вспоминать» - он найдет нужную информацию и ответит более компетентно. Иногда возникает необходимость в зоне «ОЧЕНЬ ГОРЯЧИЕ НОВОСТИ!». К этому разряду можно отнести объявление о крупных скидках, которые действуют только несколько дней, или объявление о проведении какого-либо крупного мероприятия (семинара, выставки). Подробная информация, как правило, заносится в документ базы «Новости», но дополнительно на Home Page помещается «красочный плакат» с линком на этот документ. Хороший способ получить такой линк - открыть броузером вид, в котором отображается документ, и скопировать ссылку на него (copy link location). Если изображение вставлено в документ (Import, Paste) или ссылка на изображение «написана» способом [], то «вокруг нее» можно создать hotspot типа link hotspot, предварительно скопировав документ как doclink. В Notes версии 4.6, в отличие от версии 4.5, hotspot'ы, «сделанные вокруг» текста стиля HTML, не работают. Что же касается именно обслуживания сайта, то полезно делать следующее. 1. Периодически проверять, «отвечает ли» сайт и насколько быстро он работает. 2. Следить за регистрацией Web-пользователей (некоторые регистрируются по несколько раз из-за того, что забывают свои имена или пароли). Наиболее «настойчивым» можно послать письмо по е-mail и объяснить, как осуществляется регистрация. 3. Быть в курсе изменений в ACL баз на сайте, включая изменения в составе групп. 4. Добавляя на сайт новые базы, не забывайть включать их в список баз, по которым производится поиск на сайте (Multi database search). Поисковая база «вяло реагирует» на изменение списка баз, так что может понадобиться удалить ее полнотекстовый индекс и затем построить заново.
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 93
9. Конфигурирование Web-сервера Domino версий 4.6.x Web-сервер Domino представляет собой задачу с именем HTTP, запускаемую на сервере Notes и позволяющую клиентам, оснащенным Web-броузерами, получать доступ как к информации из баз данных, находящихся на сервере Notes, так и к HTML-файлам, CGIпрограммам и сервлетам, находящимся в каталогах компьютера сервера Notes Задача HTTP загружается командой Load http, a завершается командой Tell http quit. Чтобы задача автоматически запускалась при старте сервера, ее имя следует внести в список задач в переменной ServerTasks в файле NOTES.INI. Статистика работы сервера Domino может быть получена командой консоли Show stat domino. Основные настройки для задачи HTTP задаются в секциях Internet Port and Security Configuration и HTTP Server документа Server из общей адресной книги.
9.1.
Настройки в документе Server
9.1.1. Секция Internet Port and Security Configuration документа Server В этой секции задаются номера и статус портов TCP/IP, по которым задача HTTP должна ожидать обращений клиентов, а так же возможность «анонимного» доступа и (или) применяемые варианты аутентификации клиентов.
Рис. 9.1 Секция Internet Port and Security Configuration в документе Server TCP/IP port number (по умолчанию 80). Задает номер порта, на котором сервер Domino должен «ожидать» запросы по «обыкновенному» протоколу HTTP. Стандартно для протокола HTTP используется порт 80. Не используйте значений, меньших чем 1024 (кроме стандартного 80), поскольку они зарезервированы для других прикладных программ TCP/IP. Если задается нестандартный номер порта, клиенты будут вынуждены явно указывать этот номер порта в URL. Например, URL http://domino.lotus.com:8080/ «запрашивает» начальную страницу с хоста domino.lotus.com, который «ожидает» запросы по протоколу HTTP на порту 8080. После изменения номера порта, чтобы эти изменения «вступили в силу», сервер Notes следует перезапустить.
© InterTrust Co. Тел. 956-7928
94
Конфигурирование Web-сервера Domino версий 4.6.x
TCP/IP port status (по умолчанию Enabled). Выбор Enabled разрешает серверу Domino обслуживать запросы по «обыкновенному» протоколу HTTP, выбор Disabled - запрещает обслуживать запросы по «обыкновенному» протоколу HTTP, а выбор Redirect to SSL требует «перенаправлять» запросы на порт с поддеркой SSL (по тому же URL, но c «префиксом протокола» https://). Должно быть разрешено обслуживание запросов хотя бы по одному из двух возможных портов: «обыкновенному» (TCP/IP port status) или с поддержкой SSL (SSL port status). Если обслуживание запрещено по обоим портам, Domino не сможет функционировать. SSL port number (по умолчанию 443). Задает номер порта, на котором сервер Domino должен «ожидать» запросы по протоколу HTTP с поддержкой SSL. После изменения номера порта, чтобы изменения «вступили в силу», сервер Notes следует перезапустить. SSL port status (по умолчанию Disabled). Выбор Enabled разрешает серверу Domino обслуживать запросы по протоколу HTTP с поддержкой SSL, а выбор Disabled - запрещает. Бессмысленно «разрешать» поддерку SSL, если для сервера не создан KeyRing-файл (его имя должно задаваться в поле SSL key file). Вопросы поддержки SSL подробно рассматриваются в следующей главе. При работе по «обыкновенному» протоколу HTTP возможен как «анонимный» доступ (Yes в поле в строке Anonymous в верхней половине таблицы), так и аутентификация клиента по введенным им имени и паролю (Yes в поле в строке Name & password в верхней половине таблицы). Если разрешен «анонимный» доступ, обратившийся к серверу HTTP-клиент «будет фигурировать на сервере» под именем Anonymous. Доступ такого клиента в каждой базе Notes определяется прежде всего списком управления доступом этой базы: как Anonymous или, если в ACL отсутствует имя Anonymous, как -Default-, но не выше максимального уровня доступа для HTTP-клиентов (поле Maximum Internet name & password access в ACL базы). Чтобы стала возможной аутентификация клиента по введенным им имени и паролю, для клиента в любой из доступных серверу адресных книг необходимо создать документ Person с именами в полях User name и Short name и паролем в поле Internet password.
Рис. 9.2 Фрагмент документа Person Когда клиент получает в броузере запрос на ввод имени и пароля, он может ввести любое из имен, присутствующих в полях User name или Short name его документа Person. Если по полученному от клиента имени сервер находит в доступных ему адресных книгах единственный документ Person, то, после успешного сравнения паролей, данный HTTP-клиент «станет фигурировать на сервере» под именем, которое «записано первым» в поле User name его документа Person. Именно это «Notes-имя HTTP-клиента» - первый элемент из поля-списка
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 95
User name - администратор сервера должен использовать в ACL баз Notes или в группах в общей адресной книге сервера. Доступ HTTP-клиента к базе Notes определяется доступом к базе «Notes-имени этого HTTP-клиента», но не будет превышать максимального уровня доступа для HTTP-клиентов (поле Maximum Internet name & password access в ACL базы). Если на сервере разрешена аутентификация клиента по введенным им имени и паролю (Yes в поле в строке Name & password в верхней половине таблицы на Рис. 9.1), но «анонимный» доступ запрещен (No в поле в строке Anonymous в верхней половине таблицы), все HTTPклиенты при обращении к серверу Domino «сразу» получают запрос на ввод имени и пароля. Если же на сервере разрешены как аутентификация клиента по введенным им имени и паролю (Yes в поле в строке Name & password в верхней половине таблицы), так и «анонимный» доступ (No в поле в строке Anonymous в верхней половине таблицы), все зависит от списка управления доступом базы, к которой обращается HTTP-клиент. Если к этой базе возможен «анонимный» доступ, то запроса на ввод имени и пароля не последует. Если же Anonymous и -Default- не имеют доступа к базе, клиенту придется ввести имя и пароль. При работе по протоколу HTTP с поддержкой SSL возможны «анонимный» доступ (Yes в поле в строке Anonymous в нижней половине таблицы на Рис. 9.1), аутентификация клиента по введенным им имени и паролю (Yes в поле в строке Name & password в нижней половине таблицы) и аутентификация клиента по информации из его сертификата стандарта X.509 (Yes в поле в строке Client certificate в нижней половине таблицы). Последний вариант аутентификации возможен только с версии 4.6 и удобен тем, что клиенту не требуется вводить имя и пароль.
9.1.2. Секция HTTP Server документа Server Рассмотрим, группа за группой, многочисленные поля этой секции.
Рис. 9.3 «Начало» секции HTTP Server
Группа полей Basics Host name (по умолчанию пусто). Поле должно содержать хост-имя компьютера, на котором установлен сервер Domino. Это может быть любое из хост-имен, определеных для вашего компьютера на DNS-сервере. Если ваш компьютер не имеет зарегистрированного на сервере DNS хост-имени, можно задать в этом поле IP-адрес вашего компьютера. Но при этом случае клиенты будут вынуждены задавать в URL его IP-адрес, например, http://194.220.133.11/.
© InterTrust Co. Тел. 956-7928
96
Конфигурирование Web-сервера Domino версий 4.6.x
Если вы оставите поле Host name пустым, Domino будет использовать хост-имя, определенное в стеке протокола TCP/IP операционной системы. Bind to host name (по умолчанию Disabled). Выбирать в этом поле значение Enabled следует только в том редком случае, когда на вашем компьютере установлены несколько серверов Domino (partitioned server), поддерживающих более одной задачи HTTP. В такой ситуации нужно «уточнить», по какому IP-адресу должно производиться обращение к задаче HTTP на конкретном сервере Domino. Это и достигается указанием в поле Host name IP-адреса или имени хоста (что определяет IP-адрес) и выбором Enabled в поле Bind to host name. Например, на одном компьютере, имеющем IP-адреса 194.220.133.11 (www1.acme.com) и 194.220.133.12 (www2.acme.com), установлены два сервера Domino (NotesServer1/Acme/US и NotesServer2/Acme/US). В документе Server для NotesServer1/Acme/US в поле Host name содержится www1.acme.com, а в документе Server для NotesServer2/Acme/US соответственно www2.acme.com. В обоих документах Server в поле Bind to host name выбрано Enabled. В результате обращения по URL http://www1.acme.com/… обрабатываются задачей HTTP сервера NotesServer1/Acme/US, а обращения по URL http://www2.acme.com/… обрабатываются задачей HTTP сервера NotesServer2/Acme/US. Если же на компьютере установлен один сервер Domino, и вы хотите поддерживать на нем одной задачей HTTP несколько виртуальных Web-серверов, то в поле Bind to host name должно быть выбрано Disabled. DNS lookup (по умолчанию Disabled). Выберите Enabled, если требуется, чтобы сервер Domino выполнял поиск хост-имени каждого своего клиента по его IP-адресу, обращаясь к серверам DNS. Выбор Enabled несколько ухудшает эффективность работы сервера Domino, однако в протоколах работы сервера Domino будут содержаться хост-имена клиентов, а не IPадреса, и в фильтрах протоколирования вы сможете использовать как маски на основе хостимен клиентов, так и маски на основе IP-адресов клиентов. Если же выбрано Disabled, сервер Domino не обращается к серверам DNS для определения хост-имени клиента. Выбор Disabled улучшает эффективность работы сервера Domino, однако в протоколах работы Domino будут содержаться только IP-адреса клиентов и в фильтрах протоколирования вы сможете использовать маски только на основе IP-адресов клиентов. Default home page (по умолчанию default.htm). Если в качестве начальной страницы (home page) должен использоваться обычный файл в формате HTML, укажите в этом поле имя файла и «очистите» поле Home URL в группе полей Mapping. Тогда, если в URL запроса клиента не указана конкретная страница (http://host-name/), сервер Domino, «обнаружив», что поле Home URL «пусто», будет загружать клиенту этот файл из каталога, указанного в поле HTML directory (обычно, domino\HTML). Если же в качестве начальной страницы должен использоваться какой-то элемент из базы данных Notes (например, документ About или навигатор), оставьте в поле Default home page его значение по умолчанию, а в поле Home URL укажите соответствующий «относительный» URL, например, что-то подобное /home.nsf?OpenDatabase для документа About или /home.nsf/Main+Navigator?OpenNavigator для навигатора. Allow HTTP clients to browse databases (по умолчанию Yes). Если в поле выбрано Yes, клиенты, указав URL http://host-name/?OpenServer, смогут получить список баз данных на сервере Notes, а из него, «переходя по ссылкам», предпринимать попытки открыть и сами базы. Когда же выбрано No, клиенты не смогут получить список имеющихся на сервере баз, но смогут открывать конкретные базы данных, если знают их имена файлов и имеют к ним доступ. Maximum requests over a single connection (по умолчанию 5). Максимальное число HTTPзапросов за одно соединение. Number active threads (по умолчанию 40). Задает максимально возможное количество параллельно работающих подпроцессов (thread's), порождаемых задачей HTTP. Если заданный максимум достигнут, сервер Domino «отказывается отвечать» на новые запросы, пока уже принятые им запросы не будут обслужены и исполнявшие их подпроцессы не освободятся. Чем
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 97
более мощный компьютер используется в качестве сервера, тем и большее максимально возможное количество подпроцессов должно задаваться в этом поле. Однако выбор слишком большого значения может привести к излишней трате ресурсов компьютера на «прокачку страниц» между оперативной памятью и файлом страниц. На платформе Windows NT рекомендуется экспериментально исследовать этот вопрос с применением приложения Performance Monitor. Minimum active threads (по умолчанию 20). В версиях «ниже» 4.6 задает минимальное количество подпроцессов, всегда поддерживаемых задачей HTTP. Сервер Domino не должен закрывать подпроцессы «ниже этого минимума», даже если они неактивны, т.е. не обслуживают запросы. Подпроцессы же «сверх этого минимума» при переходе в неактивное состояние должны закрываться задачей HTTP и открываться снова, когда это требуется. Начиная с версии 4.6 поле Minimum active threads не используется.
Группа полей Mapping Группа полей Mapping задает реальное местоположение каталогов HTML-файлов, пиктограмм и CGI-программ и определяет URL для доступа к ним. Учтите, что на одном компьютере «под одним сервером Notes» может функционировать несколько виртуальных серверов Domino (рассматривается в 9.2). В этом случае для каждого виртуального сервера Domino информация из группы полей Mapping «перекрывается» аналогичной информацией из документов Virtual Server базы данных DOMCFG.NSF. Home URL (по умолчанию /?Open). Относительный URL элемента из базы данных Notes (например, документа About или навигатора), HTML-образ которого Domino должен возвращать, когда клиенты «входят на сервер», не указывая в URL требуемый им каталог или страницу (http://host-name/). Использование значения по умолчанию /?Open влечет отображение списка баз данных, имеющихся на сервере (как по File - Database - Open в клиенте Notes). Если же вы используете начальную страницу (home page) непосредственно в формате HTML, «очистите» поле Home URL и укажите имя HTML-файла в поле Default home page. HTML directory (по умолчанию domino\html). Каталог для HTML-файлов. Если указан не полный путь, он «отсчитывается» относительно каталога данных Notes. Icon directory (по умолчанию domino\icons). Каталог пиктограмм Domino. Если указан не полный путь, он «отсчитывается» относительно каталога данных Notes. Icon URL Path (по умолчанию /icons). Относительный URL для каталога пиктограмм Domino. Например, чтобы «открыть в броузере» файл abook.gif или форму search.htm, находящиеся в подкаталоге domino\icons каталога данных Notes, необходимы URL http://hostname/icons/abook.gif или http://host-name/icons/search.htm. В большинстве случаев не следует изменять исходное значение этого поля. CGI directory (по умолчанию domino\cgi-bin). Каталог для программ CGI. Если указан не полный путь, он «отсчитывается» относительно каталога данных Notes. CGI URL path (по умолчанию /cgi-bin). Относительный URL для каталога программ CGI на сервере Domino. Например, для запуска CGI-программы CGITest.exe, находящейся в подкаталоге domino\cgi-bin каталога данных Notes, необходим URL http://host-name/cgibin/CGITest.
Группа полей Disk Cache for Images and Files Эта группа полей (Рис. 9.4) «отвечает» за управление файловым кэшем. Файловый кэш содержит файлы изображений и присоединенные файлы. Cache directory (по умолчанию domino\cache). Определяет каталог, который сервер Domino должен использовать для сохранения графических и присоединенных файлов. Когда клиент запрашивает страницу с элементами графики, Domino преобразует каждый графический
© InterTrust Co. Тел. 956-7928
98
Конфигурирование Web-сервера Domino версий 4.6.x
элемент в файл соответствующего графического формата, передает файл клиенту и сохраняет копию файла в каталоге кэша. Если Domino получает другой запрос на ту же самую страницу, он уже передает клиенту соответствующие файлы непосредственно из кэша. То же самое происходит и с присоединенными файлами - будучи «отсоединенными» из документа Notes для передачи клиенту, они «попадают» в кэш, а откуда в течение некоторого времени могут повторно использоваться Domino. Если в поле указывается не полный путь, то считается, что он был задан относительно каталога данных Notes. Garbage collection (по умолчанию Enabled) и Garbage collection interval (по умолчанию 60 минут). Чтобы не допустить «разрастания» кэша сверх максимального размера, рекомендуется разрешить (выбором значения Enabled в поле Garbage collection) периодическое выполнение сервером Domino процесса «уборки мусора». Процесс «уборки мусора» удаляет файлы из кэша, начиная с наименее часто используемых. Период, с которым запускается процесс «уборки мусора», запускается в поле Garbage collection interval.
Рис. 9.4 Продолжение секции HTTP Maximum cache size (по умолчанию 50 MB). Максимальное количество дискового пространства, доступного для кэша (в МБ). Размер кэша обычно остается ниже заданного максимума, но может иногда становиться и немного большим. Когда максимальный размер кэша достигнут, автоматически запускается процесс «уборки мусора». Если никакое значение не задано (поле Maximum cache size пустое), сервер Domino вообще не применяет кэширование файлов. Delete cache on shutdown (по умолчанию Disabled). Если выбрано Enabled, Domino будет «очищать кэш» при остановке сервера Notes. Если же выбрано Disabled, при перезапусках сервера Notes кэш будет сохраняться.
Группа полей Memory Caches В дополнение к файловому кэшу для повышения производительности HTTP-сервера с версии 4.6 введены три кэша в виртуальной памяти.
•
Кэш HTML-страниц. На генерацию кода HTML-страницы по информации из базы данных Notes, в отличие от обращения к «уже готовому» HTML-файлу, затрачивается некоторое
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 99
время. Чтобы способствовать уменьшению времени отклика для клиента, задача HTTP предпринимает попытку кэшировать генерируемый ею по запросам клиентов HTML-код. Поэтому последующие обращения клиентов по URL, соответствующему имеющейся в кэше HTML-странице, могут отрабатываться быстрее, если только «прообраз» кэшируемой страницы в базе Notes не успел измениться. В поле Maximum cached HTTP commands задается максимальный размер этого кэша. Кэширование выполняется не для всех страниц, а только для тех, которые являются «достаточно статическими». «Потенциальными кандидатами» для кэширования выступают лишь страницы, в URL которых имеются «операции» ?OpenDatabase, ?OpenView, ?OpenDocument, ?OpenForm и ?ReadForm. Прочие страницы (например, ?EditDocument) вообще никогда не заносятся в кэш. В версии 4.6 факт присутствия @-функций в «прообразе» страницы безусловно означал исключение этой страницы из числа «кандидатов для кэширования». С версии 4.6.1 страницы, «прообразы» которых содержат @-функции, могут кэшироваться. В Domino 4.6.1 в состав задачи HTTP включен анализатор @-формул (Formula Analyzer). Анализируя @-формулы «прообраза страницы», он «дает заключение» об уровне изменчивости страницы, стратегии для кэширования этой страницы и условиях, при возникновении которых кэшируемая страница должна считаться «устаревшей». Однако «по умолчанию» для совместимости с версией 4.6 анализатор формул не функционирует, т.е. страницы с @-формулами не кэшируются. Чтобы «включить» анализатор формул, нужно добавить в файл NOTES.INI сервера переменную DominoAnalyzeFormulas=1. Прежде всего анализатор формул вычисляет по «прообразу» страницы набор флагов:
• • • • • • • • • • •
OffDb - используются данные, получаемые не из текущей базы, например, переменные CGI; TimeVariant - зависит от времени, например, используется @Now; HadEffect - имеет посторонние эффекты, например, используется @DialogBox; UsedEnv - используются переменные из файла NOTES.INI; UserVariant - зависит от имени пользователя, например, в данных или элементах дизайна используются обращения к ACL, поля типа Readers или Authors, секции с управляемым доступом…; DesignUserVariant - используются «закрытые» элементы дизайна; DbData - используются данные не только из конкретного документа, например, в форме применены Embedded View, Embedded Folder Pane…; UsedDocId - используются идентификаторы документов; UsedNewDoc - «прообраз» страницы создан в виртуальной памяти и не сохранен в базе; Unknown - используется такое, что анализатор формул «не способен понять», например, LotusScript; Error - имеются ошибки.
Затем анализатор формул вычисляет стратегию кэширования данной страницы. Выбранная стратегия описывается набором из следующих:
• • • • •
DontCache - не кэшируется; Document - кэшируется, устаревает при изменении документа; DbDesign - кэшируется, устаревает при изменении документа; DbData - кэшируется, устаревает при любых изменениях в базе; OnlyAnonymous - кэшируется, но берется из кэша только для передачи анонимным пользователям.
© InterTrust Co. Тел. 956-7928
100
Конфигурирование Web-сервера Domino версий 4.6.x
Страницы с флагами OffDb, TimeVariant, HadEffect, UsedEnv, Error, Unknown, UserVariant и DesignUserVariant не кэшируются - «используется стратегия» DontCache. Поскольку анализатор формул в принципе не может быть настолько совершенным, чтобы всегда давать правильное заключение о необходимой стратегии кэширования, предусмотрены и средства, позволяющие разработчику управлять стратегией кэширования конкретных страниц «вручную». Для этого в документах и формах применяются следующие поля.
• •
$CacheOptions - если значение текстового поля равно "0", то кэширование не должно выполняться. $CacheValid - текстовое поле содержит количество секунд "N", в течении которых механизму кэширования «запрещается проверять», не устарела ли страница. Аналогичное значение по умолчанию «для всего сервера» может задаваться переменной DominoDefaultCacheValid=N в файле NOTES.INI. Например, имеется страница, соответствующая в базе документу со «статическими» @-формулами. Эту страницу регулярно и часто, пусть, раз в минуту, «читают» HTTPклиенты. К тому же содержание документа регулярно изменяется, но частота его изменения в несколько, допустим, в 10 раз, превышает частоту обращений к странице. Скорее всего, анализатор формул предложит для этой страницы стратегию Document. В результате задача HTTP каждую минуту будет проверять, не изменился ли документ. Можно поменять стратегию кэширования, добавив в документ поле $CacheValid со значением "300". Это означает, что в течении 300 секунд (5 минут) после обновления HTML-образа документа в кэше при очередных 4-5 обращениях HTTP-клиентов страница будет возвращается им из кэша без проверки, не изменился ли документ. По прошествии 5 минут будет восстановлена предложенная анализатором стратегия, и при каждом последующем обращении станут выполняться проверки изменения документа.
Заметим, что если в файл NOTES.INI добавить переменную DominoTraceCmdCache=1, то информация о стратегии кэширования будет помещаться в HTML-заголовок страницы. Описания добавляемых в заголовок атрибутов и способы наблюдения за изменениями этих атрибутов имеются в статье Andrew Wharton «Expanded Command Caching in Domino 4.61», которую можно найти «в базе» http://www.notes.net/home.nsf/.
•
Кэш с информацией для быстрого доступа к элементам дизайна баз данных. Когда клиент броузера «впервые открывает» базу данных, задача HTTP просматривает все элементы дизайна базы (формы, виды, агенты…) и создает таблицу, сопоставляющую имени каждого элемента дизайна его идентификатор. Эта таблица позволяет по идентификаторам более быстро извлекать из базы те элементы дизайна, которые нужны для генерации HTML-страницы, запрошенной клиентом (например, форму «для показа» документа). Кэширование таких таблиц в виртуальной памяти способствует уменьшению времени отклика для клиентов. В поле Maximum cached designs задается максимальный размер этого кэша.
•
Кэш с информацией об именах и паролях аутентифицированных пользователей и их принадлежности к группам. Когда клиент броузера впервые обращается в базе, «требующей» аутентификации клиента, ему приходится ввести свое имя и пароль. По завершении процесса аутентификации имя, пароль и информация о принадлежности этого имени к группам из адресной книги помещается в кэш и содержится в нем в течении указанного в поле Cached users expiration interval количества секунд. Если клиент вновь обращается к базе данных, «требующей» аутентификации, но информацию об этом клиенте удается найти в кэше, клиенту не требуется в очередной раз вводить имя и пароль, а серверу – выяснять принадлежность клиента к группам. В поле Maximum cached users задается максимальный размер этого кэша.
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 101
Протоколирование обращений к серверу Domino По каждому HTTP-запросу, выполняемому броузером, сервер Domino способен протоколировать следующую информацию: с какого IP-адреса (или DNS-имени) поступил запрос, какой броузер использует клиент, какой URL использовался для доступа, сколько байт передано, какие ошибки (если были) сгенерированны программами CGI. Протоколируемая информация может быть сохранена или в текстовом файле, или в базе данных Notes с именем DOMLOG.NSF, или в обоих местах сразу. Протоколирование в текстовые файлы «включается» в поле Log files, а протоколирование в базу данных DOMLOG.NSF – в поле Domlog.nsf. База данных DOMLOG.NSF создается в каталоге данных Notes по шаблону Domino Web Server Log (DOMLOG.NTF). Протоколирование в базу данных Notes обычно более удобно, но оно требует привлечения несколько больших ресурсов компьютера, чем протоколирование в текстовый файл. При протоколировании в текстовые файлы в поле Access log format можно выбрать менее подробный (Common) или более подробный (Extended Common) формат файла Access log (ACCESS-LOG). Поле Time format определяет формат, в котором записывается время обращения. Файлы ежедневных протоколов создаются в каталоге, указанном в поле Directory for log files, причем в день создается пять файлов: Access log (ACCESS-LOG), Agent log (AGENT-LOG), Error log (ERROR-LOG), CGI error log (CGI-ERROR-LOG), Referer log (REFERER-LOG). В скобках указаны «имена по умолчанию» для этих файлов. Имена файлов могут быть изменены в «одноименных» полях. В качестве расширения для файлов выбирается дата их создания. В группе полей Exclude From Logging определяются «исключения из протоколирования»:
• • • • • •
URLs – список URL или «шаблонов» URL, например *.gif. Methods – список запросов, например, POST и DELETE. MIME types – список MIME-типов, например image/gif. User agents – список броузеров, например Mozilla. Return codes – список кодов возврата, например 300. Hosts or domains – список IP-адресов, имен хостов или их «шаблонов», например 130.333.* или *.edu.
Кроме того, имеется возможность протоколировать информацию об обращениях к серверу из броузеров с помощью серверной задачи Billing. Для этого в файле NOTES.INI сервера в список переменной BillingClass нужно добавить протоколирование HTTP-запросов, например: BillingClass=Session, Database, Document, Replication, Mail, Agent, HttpRequest . К сожалению, при всем богатстве выбора протоколы обычно имеют большой размер и не удобны для анализа.
Группа полей Timeouts Группа полей Timeouts задает временные ограничения для контактов между сервером Domino и клиентом. Input timeout (по умолчанию 2 минуты). Максимальное время в минутах с момента установления клиентом HTTP-соединения с сервером Domino до посылки клиентом запроса на ресурс (GET URL). Если клиент не посылает запрос за заданное время, сервер Domino разрывает HTTP-соединение с ним. Output timeout (по умолчанию 20 минут). Максимальное время в минутах, отводимое на передачу данных сервером Domino (но не запущенной им CGI-программой) клиенту. По истечении этого времени сервер Domino «разрывает» HTTP-соединение с клиентом. Ограничение касается запросов на получение локальных файлов и информации из баз данных Notes, но не касается запросов, выполнение которых влечет запуск программ CGI.
© InterTrust Co. Тел. 956-7928
102
Конфигурирование Web-сервера Domino версий 4.6.x
CGI timeout (по умолчанию 5 минут). Максимальное время в минутах, отводимое на работу программе CGI, запущенной сервером Domino. Когда отведенное время истекает, сервер Domino посылает программе CGI сообщение. Затем, еще через пять минут, сервер Domino «снимает» эту программу. Idle thread timeout (по умолчанию 0 минут). С версии 4.6 поле не используется. В версиях до 4.6 задавало интервал времени в минутах, в течение которого сервер Domino не должен был закрывать неактивный подпроцесс. Подпроцесс становился неактивным после того, как он выполнял свой последний запрос. Если текущее количество подпроцессов было больше, чем указано в поле Minimum active threads, и сервер Domino не использовал некоторый подпроцесс в течение заданного интервала времени, сервер закрывал этот подпроцесс. Чтобы Domino вообще не закрывал неактивные подпроцессы, в поле задавалось значение 0.
Рис. 9.5 «Окончание» секции HTTP
Группа полей Conversion/Display Определяет формат и стиль отображения графики, а так же отображение информации из видов. Image conversion format (по умолчанию GIF). Domino может преобразовывать графические элементы из форм и документов Notes или в формат GIF, или в формат JPEG. В зависимости от того, какой из форматов был выбран вами в данном поле, будут присутствовать или отсутствовать следующие поля. (Выбран GIF) Interlaced rendering (по умолчанию Enabled). Если выбрано Enabled, Domino создает GIF-файлы в «чередуемом» формате. В GIF-файле «чередуемого» формата строки изображения сохранены не в обычной последовательности (строка за строкой от первой до последней), а, например, вначале каждая восьмая строка изображения, затем каждая четвертая строка изображения, затем каждая вторая строка... Поэтому GIF-файл «чередуемого» формата в процессе загрузки в броузер отображается в окне броузера, как бы «приобретая все более и более четкие очертания». Поскольку глаз человека обладает свойством «восстанавливать» отсутствующие части изображения, у клиента создается впечатление, что загрузка изображения происходит быстро. Если же выбрано Disabled, Domino создает файлы GIF в обычном формате - такое изображение в окне броузера появляется «сверху вниз строка за строкой». (Выбран JPEG) Progressive rendering (по умолчанию Enabled). Если выбрано Enabled, Domino создает JPEG-файлы в «прогрессирующем» формате. Броузеры обычно загружают и отображают JPEG-файл обычного формата за один проход. JPEG-файл в «прогрессирующем» формате загружается и отображается за несколько проходов: изображение в окне броузера с каждым проходом приобретает «все более и более четкие очертания». В результате клиент может «идентифицировать» возникающее изображение прежде, чем оно полностью загружено в броузер. (Выбран JPEG) JPEG image quality (по умолчанию 75). Целое число в диапазоне от 5 до 100 (процентов), определяющее «качество изображения» в создаваемом Domino JPEG-файле.
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 103
Большие значения - больший по размеру файл и лучшее качество изображения, малые значения - меньший по размеру файл, меньшее количество времени на загрузку, но более низкое качество изображения. Default lines per view (по умолчанию 30). Количество строк из вида в базе данных Notes, возвращаемое сервером Domino в броузер за один запрос. Это лишь «значение по умолчанию», но оно касается всех баз на сервере. Клиент броузера в каждом конкретном случае может изменить получаемое им количество строк из вида, указав в URL параметр &Count наподобие http://host-name/db-name.nsf/view-name?OpenView&Start=1&Count=999&ExpandView.
Группа полей Character Set Mapping Default character set group (по умолчанию Western). Набор символов, в котором HTMLтекст будет предоставляться клиенту. Возможные варианты: Western, Central European, Japanese, Traditional Chinese, Simplified Chinese, Korean, Cyrillic, Greek, Turkish, Thai и Multilingual. Чтобы обеспечить поддержку «русских букв», выбирают Cyrillic. Character set mapping (по умолчанию Latin1). Сервер Domino использует заданный в поле Default character set group набор символов и заданную в поле Character set mapping (Рис. 9.7) таблицу кодов символов при создании HTML-текста для броузера. Выбор в поле Character set mapping зависит от выбора в поле Default character set group. Если Default character set group = Cyrillic, в поле Character set mapping можно выбрать таблицы кодов символов ISO-8859-5, CP1251 или KOI8-R. Имеется возможность выбирать нужный набор символов (например, Western, Cyrillic, Greek…) при создании из броузера новых документов. Для этого в поле Default character set group должно быть выбрано Multilingual (Native Code Page) или Multilingual (ISO10646). Только тогда появится возможность выбрать для каждого набора символов необходимую кодовую страницу (но только по одной для каждого набора!).
Рис. 9.6 Группа полей Character Set Mapping при выборе Multilingual (Native Code Page)
Рис. 9.7 «Выпадающий список» для выбора нужного набора символов при создании документа из броузера © InterTrust Co. Тел. 956-7928
104
Конфигурирование Web-сервера Domino версий 4.6.x
Пользователь броузера, создавая «в базе» новый документ, обнаружит «в конце» этого документа поле типа «выпадающий список» с меткой Select Encoding, позволяющее выбрать желательный ему набор символов. Возможность же выбирать в рамках одного набора символов несколько кодовых страниц, например KOI8-R или Windows-1251 для Cyrillic, отсутствует.
9.2.
База данных Domino Web Server Configuration
1.1.1. Виртуальные серверы Domino (hosting multiple sites on one server) На одном компьютере, «несущем» один сервер Notes и одну задачу HTTP, может функционировать несколько виртуальных серверов Domino. Каждый виртуальный сервер Domino имеет собственные имя хоста, «начальную» страницу и каталоги HTML, CGI и Icons, но при этом структура каталога данных Notes для всех виртуальных серверов Domino остается одинаковой. Наличие собственного IP-адреса для каждого виртуального сервера совсем не обязательно. На сервере Notes создается база данных DOMCFG.NSF по шаблону Domino Configuration (DOMCFG.NTF). В этой базе для каждого «очередного» виртуального сервера Domino создается документ Virtual Server. Чтобы выполненные изменения «вступили в силу», перезапускают задачу HTTP. Таким образом, настройки для «первого» сервера Domino задаются в секции HTTP Server из документа Server, а настройки «очередных» получаются из настроек «первого» сервера Domino заменой значений «одноименных» полей на значения из соответствующего документа Virtual Server.
Рис. 9.8 Документ Virtual Server Поясним это на примере. Предположим, что имена хостов www.inttrust.ru и main.inttrust.ru имеют один и тот же IP-адрес 195.208.68.130 (main.inttrust.ru – имя хоста, а www.inttrust.ru – его алиас), а имя хоста main-int.inttrust.ru имеет IP-адрес 195.208.68.1. Пусть в секции HTTP Server документа Server в поле Host name указано main-int.inttrust.ru, а в поле Bind to host name выбрано Disabled. В базе DOMCFG.NSF создадим два документа Virtual Server, указав в поле с меткой IP Address (не обращайте внимания на семантику метки поля!) для одного «текст» main.inttrust.ru, а для другого - «текст» www.inttrust.ru, а в полях с меткой Home URL соответствующие «начальные» страницы. Перезапустим задачу HTTP. Клиент, обращающийся к HTTP-серверу по URL http://main-int.inttrust.ru, будет «попадать» на указанную в секции HTTP Server документа Server «начальную» страницу. «Получив» URL http://main.inttrust.ru или http://www.inttrust.ru, задача HTTP «решает вопрос», какому же виртуальному серверу
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 105
соответствует этот URL, непосредственно по содержащемуся в URL имени хоста (main.inttrust.ru или www.inttrust.ru) и «отправляет клиента» на указанную в соответствующем документе Virtual Server «начальную страницу». Теперь добавим в базу DOMCFG.NSF третий документ Virtual Server, указав в поле IP Address «текстовую строку» «195.208.68.130» и соответствующую ей «начальную» страницу. И после перезапуска задачи HTTP ее поведение может показаться … совершенно необъяснимым. По мнению автора, все зависит от того, в каком порядке оказались расположенными наши документы Virtual Server в «скрытом несортированном» виде ($Virtual Servers). Обратите внимание, что в рассматриваемом случае www.inttrust.ru и main.inttrust.ru имеют IP-адрес 195.208.68.130. Если порядок «сверху вниз по виду» 195.208.68.130 ! www.inttrust.ru ! main.inttrust.ru, то «два последних» документа вообще не будут функционировать, т.е. обращаясь по URL http://main.inttrust.ru или http://www.inttrust.ru, вы будете попадать на начальную страницу, указанную в документе для 195.208.68.130. Если порядок www.inttrust.ru ! 195.208.68.130 ! main.inttrust.ru, не будут функционировать «последний» документ. Вероятно, причина «столь замысловатого поведения» объясняется тем, что в Domino версий 4.5x для каждого виртуального сервера требовался свой собственный IP-адрес, а в версиях 4.6x, как показывает практика, это не обязательно. Поэтому, чтобы «не попадать в зону неопределенности», можно порекомендовать указывать в документах Virtual Server и в поле Host name документа Server или только имена хостов, или только IP-адреса, а не то и другое вместе. Обратите также внимание, что в базе DOMCFG.NSF имеются другие могущие оказаться полезными формы для создания документов:
• • •
Mapping URL → Directory - для перемещения каталогов HTML, CGI, images и других в новое местоположение без изменения URL, используемых клиентами для доступа к ним; Mapping URL → URL - для автоматической замены входящего URL на другой, соответствующий реальному местоположению на этом же HTTP-сервере; Redirection URL → URL - для автоматической замены входящего URL на другой, в том числе и расположенный на другом HTTP-сервере.
9.2.2. Собственные страницы «в ответ» на ошибочные ситуации Начиная с версии 4.6 имеется возможность создавать собственные страницы «в ответ» на ошибочные ситуации. Допустимы четыре категории «ответных» страниц:
• • • •
Authentication failure – задаче HTTP не удалось аутентифицировать клиента (неправильные имя или пароль); Authorization failure – согласно списку управления доступом базы клиент не имеет необходимого уровня доступа для выполнения запрошенной им операции; Document successfully deleted – «в ответ» на успешное удаление документа по запросу клиента; General error – «в ответ» на все остальные ошибки.
Во первых, такие ответные страницы могут быть определены в конкретной базе данных. Для этого в базе нужно создать четыре формы с предопределенными именами (или алиасами) $$ReturnAuthenticationFailure, $$ReturnAuthorizationFailure, $$ReturnDocumentDeleted, $$ReturnGeneralError. Если при работе с такой базой из броузера возникает ошибка соответствующей категории, клиент получает в ответ HTML-код, сгенерированный по соответствующей форме. Пример такой доработки базы можно найти в шаблоне Combined Mail (MAILC46.NTF), поставляемом с Domino 4.6. Во-вторых, для всех остальных баз, которые не имеют собственных форм «для ответа на ошибки», «типовые ответные» формы можно определить в базе данных Domino Configuration (DOMCFG.NSF). Для этого в базе DOMCFG.NSF необходимо создать один документ Mapping Error Messages для «всего» HTTP-сервера или по одному такому документу для каждого из его © InterTrust Co. Тел. 956-7928
106
Конфигурирование Web-сервера Domino версий 4.6.x
виртуальных серверов. В документе для каждой категории задается имя базы данных и название формы, в соответствии с которой должен генерироваться HTML-код «в ответ» на ошибку. Естественно, что вам также потребуется создать в указанных в документе Mapping Error Messages базах формы с указанными именами (рекомендуется создавать их непосредственно в DOMCFG.NSF). Тогда, если при работе с базой из броузера возникает ошибка, но в этой базе не определены собственные «ответные» формы, для генерации HTMLкода будут использоваться «типовые ответные» формы.
Рис. 9.9 Документ Mapping Error Messages
9.3.
Поддержка сервлетов на Web-сервере Domino 9.3.1. Что такое «сервлет»
Сервлет (servlet) представляет собой специальное приложение, написанное на языке Java и выполняющееся на Web-сервере, обеспечивающем поддержку сервлетов. Когда Web-сервер принимает от клиента запрос, URL которого «указывает на» сервлет, сервер выполняет сервлет, и вывод сервлета отправляется клиенту. Поведение сервлета во многом подобно поведению CGI-программы. Одно из основных отличий состоит в том, что сервлет не нуждается в загрузке при каждом обращении к нему - загрузка сервлета выполняется только один раз, при первом обращении. Сервлеты должны реализовывать интерфейс javax.servlet.Servlet. Обычно этого достигают, создавая класс-потомок javax.servlet.GenericServlet или javax.servlet.HttpServlet. Оба эти базовых класса реализуют интерфейс Servlet, причем HttpServlet сам является потомком GenericServlet. Когда сервлет загружается сервером, в сервлете происходит вызов метода init(). Метод init() вызывается только один раз. После того, как сервер загрузит и «инициализирует» сервлет, последний становится способен обрабатывать запросы клиентов. Каждый запрос клиента приводит к вызову в сервлете метода service(). Метод service() должен быть написан с учетом параллельного выполнения потоков (thread-safe manner), поскольку каждый новый запрос порождает новый поток, выполняющий в себе метод service(). Например, если метод service() изменяет значение некоторого поля в объекте сервлета, доступ к
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 107
этому полю должен быть синхронизирован. Если же по каким-то соображениям метод service() не должен выполняться в разных потоках, то сервлет должен реализовать интерфейс SingleThreadModel. import javax.servlet.* import java.io.* public class MyServlet1 extends HttpServlet { /* метод service() будет вызываться из многих потоков */ } import javax.servlet.* import java.io.* public class MyServlet2 extends HttpServlet implements SingleThreadModel { /* метод service() может вызываться только в одном потоке */ }
Сервлет обычно функционирует на сервере до тех пор, пока функционирует сервер или пока его не выгрузит администратор. В этом случае в сервлете вызывается метод destroy(). Метод destroy() вызывается только один раз, и должен «дождаться» завершения или принудительно завершить все потоки, выполняющие метод service(), и освободить все выделенные сервлету ресурсы. Только после этого сервлет может быть вновь загружен и инициализирован. Еще одним стандартным методом сервлета является getServletInfo(). Он должен возвращать строку (String), содержащую описание сервлета. Возвращаемый текст обычно используется средствами управления сервлетами на сервере. «Неперегруженный» метод getServletInfo() возвращает пустую строку. Если сервлет является наследником класса HttpServlet, часто перегружают не сам метод service(), а другие методы, вызываемые «родным» методом service() в зависимости от запросов клиента:
• • •
doGet() - вызывается для обработки запросов GET, условный GET и HEAD (клиент запрашивает необходимые ему данные, а сервер (сервлет) возвращает клиенту запрошенную им информацию); getLastModified() - вызывается при обработке запросов GET, условный GET и HEAD и возвращает время последней модификации запрошенного клиентом ресурса; doPost() - вызывается для обработки запроса POST (клиент заполняет форму и передает введенные данные на сервер, сервер (сервлет) принимает и обрабатывает данные и обычно отвечает клиенту подтверждением приеме данных).
«Неперегруженные» методы doGet() и doPost() возвращают код ошибки 400 (BAD_REQUEST - «Плохой» запрос от клиента), а «неперегруженный» getLastModified() отрицательное число, означающее, что время последней модификации неизвестно, а потому не должно применяться в запросе условный GET и при кэшировании. Методы service(), doGet() и doPost() получают два аргумента: объекты классов HttpServletRequest и HttpServletResponse, метод getLastModified() - один аргумент: объект класса HttpServletRequest. Эти объекты поддерживают соответственно интерфейсы javax.servlet.http.HttpServletRequest и javax.servlet.http.HttpServletResponse, которые в свою javax.servlet.ServletRequest очередь «расширяют базовые» интерфейсы и javax.servlet.ServletResponse. Класс HttpServletRequest инкапсулирует передачу информации от клиента к сервлету. Методы и свойства ServletRequest позволяет сервлету получать такую информацию, как имена параметров, переданных клиентом серверу, схему, использованную клиентом, имена хостов клиента и сервера, а также входной поток ServletInputStream, «из которого» сервлет получает данные, переданные клиентом при использовании метода POST. Класс HttpServletResponse инкапсулирует передачу информации от сервлета к клиенту. Методы и свойства ServletResponse позволяет сервлету «отвечать» клиенту: задать MIME-тип
© InterTrust Co. Тел. 956-7928
108
Конфигурирование Web-сервера Domino версий 4.6.x
«ответа» и длину содержимого (content length), а так же получить выходной поток ServletOutputStream, в который сервлет должен записывать передаваемые клиенту данные. Пример 1. Сервлет возвращает броузеру страницу, содержащую текст «Hello World». /* * @(#)HelloWorldServlet.java 1.9 97/05/22 * Copyright (c) 1995-1997 Sun Microsystems, Inc. All Rights Reserved. * CopyrightVersion 1.0 * * Перекомпилирован VisualAge for Java (Enterpise) Version 1 Patch Set 2 * Обращение: http://main.inttrust.ru/Servlet/Hello */ import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloWorldServlet extends HttpServlet { public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); ServletOutputStream out = res.getOutputStream(); out.println(""); out.println("Hello World"); out.println(""); out.println("Hello World"); out.println(""); } public String getServletInfo() { return "Create a page that says Hello World and send it back"; } } Пример 2. Сервлет принимает запрос клиента, определяет параметры запроса, распознает тип запроса (GET или PUT), выбирает данные запроса и возвращает в броузер сгенерированный в строке msg HTML-код, по смыслу являющийся протоколом запроса. /* * @(#) EchoFormServlet.java * Copyright (c) Elliotte Rusty Harold * From Book: Java Network Programming * * Перекомпилирован VisualAge for Java (Enterpise) Version 1 Patch Set 2 * Обращение: http://main.inttrust.ru/Servlet/EchoForm */ import import import import
java.servlet.*; java.servlet.http.*; java.io.*; java.util.*;
public class EchoFormServlet extends HttpServlet { public void service(HttpServletRequest request, HttpServletResponse response)
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 109 { String msg = "<TITLE>\r\n"; msg += "Form ResponseForm Response\r\n"; // Основные параметры запроса msg += "Method: " + request.getMethod() msg += "URI: " + request.getRequestURI() msg += "Protocol: " + request.getProtocol() msg += "Path Info: " + request.getPathInfo()
+ + + +
"
\r\n"; "
\r\n"; "
\r\n"; "
\r\n";
// Получение пар «имя-значение» из MIME-заголовка Enumeration e = request.getHeaderNames(); while (e.hasMoreElements()) { String header = (String) e.nextElement(); msg += header + ": " + request.getHeader(header) + "
\r\n"; } msg += "
"; // Получение данных формы String qs = ""; if (request.getMethod().equals("GET")) { qs = request.getQueryString(); } else if (request.getMethod().equals("POST")) { try { DataInputStream dis = new DataInputStream(request.getInputStream()); String s; while ((s = dis.readLine()) != null) { qs += s + "\r\n"; } } catch (IOException ie) { } } else { msg += "I can't handle the " + request.getMethod() + " method.
"; } // Разбор данных на пары «имя-значение», URL decoding отсутствует if (qs != null) { StringTokenizer st = new StringTokenizer(qs, "&"); while (st.hasMoreTokens()) { String temp = st.nextToken(); String name = temp.substring(0, temp.indexOf('=')); String value = temp.substring(temp.indexOf('=') + 1, temp.length()); msg += name + ": " + value + "
\r\n"; } } // Возвращаемый клиенту HTML сгенерирован msg += "\r\n"; // Отправка его клиенту response.setContentLength(msg.length()); response.setContentType("text/html"); try {
© InterTrust Co. Тел. 956-7928
110
Конфигурирование Web-сервера Domino версий 4.6.x DataOutputStream rs = new DataOutputStream(response.getOutputStream()); rs.writeBytes("\r\n" + msg); } catch (IOException ie) { }
} } Для тестирования этого сервлета удобно использовать следующую HTML-форму с применением языка JavaScript. Форма содержит три текстовых поля и две кнопки. Одна из кнопок передает сервлету данные из полей формы методом GET («в составе URL»), а вторая - методом POST («в теле запроса»). <SCRIPT LANGUAGE="JavaScript">
В случае запроса GET сервлет возвращает броузеру приблизительно следующее. Form Response Method: GET URI: /Servlet/EchoForm?n1=v1&n2=v2&n3=v3 Protocol: http Path Info: null ACCEPT-LANGUAGE: ru,en;q=0.5 CONNECTION: Keep-Alive REFERER: http://main.inttrust.ru/eSuite.nsf/byKeys/01-xx-001?OpenDocument ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, */* ACCEPT-ENCODING: gzip, deflate USER-AGENT: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) HOST: main.inttrust.ru n1: v1 n2: v2 n3: v3 В случае запроса POST сервлет возвращает броузеру приблизительно следующее. Form Response Method: POST URI: /Servlet/EchoForm Protocol: http Path Info: null CONTENT-LENGTH: 17 CONTENT-TYPE: application/x-www-form-urlencoded ACCEPT-LANGUAGE: ru,en;q=0.5 CONNECTION: Keep-Alive
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 111 REFERER: http://main.inttrust.ru/eSuite.nsf/byKeys/01-xx-001?OpenDocument ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, */* ACCEPT-ENCODING: gzip, deflate USER-AGENT: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT) HOST: main.inttrust.ru n1: v1 n2: v2 n3: v3
Завершая экскурс в сервлеты, необходимо заметить, что данное рассмотрение преследовало лишь цель облегчить понимание вопросов конфигурирования поддержки сервлетов Webсервером Domino, и ни в коей мере не претендует на полноту освещения всех возможностей и вопросов разработки сервлетов. В частности, не следует из приведенного материала делать вывод, что «общение» между клиентом (броузером или апплетом на странице броузера) и сервлетом ограничиваются только методами протокола HTTP. Полную информацию о сервлетах и комплект разработчика сервлетов JSDK можно получить на http://jserv.javasoft.com/products/java-server/servlets/index.html. В поисках разнообразных примеров сервлетов можно обратиться на http://javashareware.com.
9.3.2. Конфигурирование поддержки сервлетов сервером Domino В настоящее время поддержка сервлетов осуществляется только сервером Domino 4.6х на платформе Windows NT/Intel. Поддерживаются сервлеты, реализующие интерфейсы JavaSoft. По умолчанию поддержка сервлетов сервером Domino «запрещена». Чтобы разрешить ее:
• •
убедитесь, что в каталоге программ сервера присутствуют файлы servlet.dll и icsclass.jar; добавьте в файл NOTES.INI сервера две переменные: • DominoEnableJavaServlets=1 - разрешает поддержку сервлетов задачей HTTP, • JavaUserClasses=c:\notes\data\domino\servlets - задает полные пути к каталогам, в которых вы будете хранить сервлеты, а так же им необходимые JAR-файлы.
Признаком того, что поддержка сервлетов разрешена, будет «автоматическое» появление в файле DOMINO.CNF (находится в каталоге данных сервера) следующих строк. #Java Servlet Settings EnableJavaServletSupport
yes
ServerInit servlet:ServletInit c:\notes\data\servlet.cnf Service /Servlet/* servlet:ServletService* ServerTerm servlet:ServletTerm
В результате этого при очередном запуске задачи HTTP будет автоматически загружаться виртуальная машина Java, которая будет пытаться найти и загрузить класс ServletManager. Этот класс, а так же прочие необходимые для поддержки сервлетов классы находятся в файле icsclass.jar. Если все успешно, вы обнаружите на консоли сервера приблизительно следующие сообщения. 25.03.98 13:48:33 25.03.98 13:48:43 25.03.98 13:48:44
HTTP Web Server started JVM: Java Virtual Machine initialized. Java Servlet Manager initialized
Сервлеты, которые должен загружать ServletManager, должны быть определены вами в файле SERVLET.CNF. Этот текстовый файл вы должны создать в каталоге данных. Например, файл может содержать следующее: #Servlet configuration settings Servlet HelloWorldServlet { }
© InterTrust Co. Тел. 956-7928
112
Конфигурирование Web-сервера Domino версий 4.6.x
Servlet EchoFormServlet { } Servlet SnoopServlet { } Servlet DateServlet { } Service Service Service Service
HelloWorldServlet /Servlet/Hello HelloWorldServlet /Servlet/EchoForm SnoopServlet /Servlet/Snoop DateServlet /Servlet/Now
В данном файле перечислены 4 сервлета: HelloWorldServlet, EchoFormServlet, SnoopServlet и DateServlet. Их файлы .class должны находиться в каталоге, указанном в переменной JavaUserClasses. Обращения же к этим сервлетам из броузера должны выполняться соотвественно по URL http://hostname/Servlet/Hello, http://hostname/Servlet/EchoForm, http://hostname/Servlet/Snoop и http://hostname/Servlet/Now. ServletManager определяет местоположение всех перечисленных в файле SERVLET.CNF сервлетов, когда запускается задача HTTP. При первом обращении к сервлету из броузера ServletManager выполняет загрузку кода этого сервлета и вызывает его метод init() с параметрами, указанными в файле SERVLET.CNF. При каждом обращении к сервлету из броузера для сервлета вызывается его метод service(). Методу service() передаются два параметра: ServletRequest - объект, представляющий запрос пользователя, и ServletResponse объект, представляющий «ответ» сервлета пользователю. Код сервлета должен быть многопоточным. При завершении задачи HTTP ServletManager вызывает для всех загруженных сервлетов их методы destroy(). Во время «первичной» загрузки сервлета приблизительно следующие сообщения:
вы
обнаружите
на
консоли
сервера
25.03.98 13:50:44 25.03.98 13:50:44 25.03.98 13:50:44 25.03.98 13:50:44 25.03.98 13:50:44 25.03.98 13:50:44 25.03.98 13:50:45 25.03.98 13:50:45 25.03.98 13:50:45
Addin: Agent printing: HelloWorldServlet: init Addin: Agent printing: Addin: Agent printing: Loaded servlet: HelloWorldServlet Addin: Agent printing: -----Servlet Information----Addin: Agent printing: Servlet Name: HelloWorldServlet Addin: Agent printing: Servlet Base Class: HelloWorldServlet Addin: Agent printing: Servlet State: READY Addin: Agent printing: Servlet configuration parameters: <none> Addin: Agent printing: Servlet Info [Servlet.toString()]: HelloWorldServlet@7d87b1
26.03.98 12:49:55 26.03.98 12:49:56 26.03.98 12:49:56 26.03.98 12:49:56 26.03.98 12:49:56 26.03.98 12:49:56 26.03.98 12:49:56 26.03.98 12:49:56 26.03.98 12:49:57
Addin: Agent printing: EchoFormServlet: init Addin: Agent printing: Addin: Agent printing: Loaded servlet: EchoFormServlet Addin: Agent printing: -----Servlet Information----Addin: Agent printing: Servlet Name: EchoFormServlet Addin: Agent printing: Servlet Base Class: EchoFormServlet Addin: Agent printing: Servlet State: READY Addin: Agent printing: Servlet configuration parameters: <none> Addin: Agent printing: Servlet Info [Servlet.toString()]: EchoFormServlet@9108bb
Средства для принудительной выгрузки сервлетов в Domino пока отсутствуют. Чтобы заменить загруженный сервлет, изменить параметры его запуска или добавить загрузку нового сервлета, вам всякий раз придется перезапускать задачу HTTP. Рассмотрим подробнее синтаксис файла SERVLET.CNF. Для каждого сервлета в файле обычно должны присутствовать две директивы. © InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 113
Директива Servlet | AdminServlet задает имя сервлета, а так же имена и значения передаваемых его методу init() параметров. В отличие от «обыкновенного» сервлета (Servlet) сервлет администратора (AdminServlet) имеет доступ к конфигурации ServletManager и может изменять ее.
{ Servlet | AdminServlet }
{
= . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . = } Директивы отображения определяет URL для обращения к сервлету. В принципе для каждой точки входа Go WebServer Application Programming Interface (GWAPI) должна указываться своя директива и свой URL. При обращении клиента по этому URL управление должно передаваться Web-сервером на однозначно связанную с директивой точку входа GWAPI. Однако в Domino версий 4.6x все эти директивы «отображаются» на метод service() сервлета. Поэтому достаточно одной директивы отображения
Service Что касается упоминания GWAPI, то, с учетом имевших место высказываний разработчиков компании IBM/Lotus, это означает планируемое в будущем слияние продуктов Go WebServer и Domino Web Server. Однако в настоящее время это пока «разные» продукты. Документацию по GWAPI можно получить с http://www.lotus.com/dominogowebserver.
9.4.
Кластеры из Web-серверов Domino: реалии и перспектива
Кластеры из серверов Notes/Domino обеспечивают балансировку загрузки (load balancing) и автоматическое перенаправление запросов, адресованных на «сильнозагруженный или неработающий» сервер-член кластера, на другой сервер-член кластера, способный обслужить этот запрос (failover). Однако полнофункционально это поддерживается в настоящее время только для клиентов Notes. Подробнее познакомиться с принципом функционирования и вопросами настройки кластеров из серверов Notes/Domino можно, например, в [3]. Простейшая попытка приблизиться к достижению подобного поведения для Web-клиентов может состоять в использовании т.н. round-robin DNS. Суть подхода состоит в том, что несколько серверов Notes/Domino, функционирующих в составе одного кластера и имеющих реплики всех доступных Web-клиентам баз данных, «назначаются на сервере DNS на одно и то же имя». Например, следующие 4 записи из файла DNS зоны inttrust.ru означают, что mainext.inttrust.ru и second-ext.inttrust.ru - имена хостов, а www.inttrust.ru - алиас для имен обоих этих хостов. main-ext second-ext www
IN IN IN IN
A A CNAME CNAME
195.208.68.130 195.208.68.132 main-ext second-ext
В этом случае «обыкновенный» DNS на запрос на имя www.inttrust.ru всегда будет возвращать IP-адрес хоста main-ext.inttrust.ru, тогда как round-robin DNS на «каждый нечетный» запрос будет возвращать IP-адрес хоста main-ext.inttrust.ru, а на «каждый нечетный» - IP-адрес second-ext.inttrust.ru. В результате поток запросов Web-клиентов может «распределяться» сервером DNS на два «синхронных» Web-сервера. Более продвинутым и интересным примером реализации «балансировки нагрузки» на основе round-robin DNS является кластер из трех Web-серверов Domino в домене Notes.Net http://www.notes.net. Серверы Domino Net1 и Net2 установлены на компьютерах с двумя процессорами Pentium II 266 МГц и оперативной памятью 512 Мб. Серверы Domino Net3 и Net4 установлены на компьютерах с двумя процессорами Pentium Pro 200 МГц и оперативной памятью 256 Мб. В состав кластера входят только серверы Net2, Net3 и Net4, и на каждом из них функционирует задача HTTP. Сервер Net1 не входит в состав кластера, но между ним и
© InterTrust Co. Тел. 956-7928
114
Конфигурирование Web-сервера Domino версий 4.6.x
одним из серверов-членов кластера осуществляются «обычные» репликации с частотой 1 минута. Люботпытно, что с сервера Net1 на серверы-члены кластера выполняются селективные репликации предоставляемых Web-клиентам баз - в репликах на серверах Net2, Net3 и Net4 присутствуют только индексы видов, необходимые Web-клиентам, но нет индексов видов, применяемых при доступе к базам из клиентов Notes. «Перед сервером управления» Net1 «находится» достаточно большое количество внутрикорпоративных серверов Notes, в репликах базах данных на которых «из клиентов Notes» и создается информация, «помещаемая затем на сайт». Настройка же round-robin DNS очевидна из Рис. 9.10.
Рис. 9.10 Схема организации кластера из трех Web-серверов в домене Notes.Net Однако в подходе на основе round-robin DNS имеются три существенных недостатка. Вопервых, сервер DNS «распределяет запросы» без всякого учета текущей рабочей загрузки Webсерверов. Во-вторых, другие DNS-серверы обычно кэшируют «удачно разрешенные ими» IPадреса и могут «не быть» round-robin DNS. В-третьих, Proxy-серверы, выполняя кэширование страниц, обычно оперируют IP-адресами в URL этих страниц, а не именами «исходных» Webсерверов. Другой подход к решению проблемы балансировки загрузки может состоять в использовании продукта IBM's Network Dispatcher (http://www.entmag.com/archive/1997/ march19/031912.html), который с учетом времени отклика обслуживаемых им Web-серверов перенаправляет «поступающие на него» запросы Web-клиентов на «наиболее быстро отвечающий» Web-сервер. Однако в настоящее время IBM's Network Dispatcher при перенаправлении запросов «принимает во внимание» только время отклика, но не реальную загрузку Domino Web-сервера или наличие на нем реплик баз данных. Но тем не менее вторая и третья проблемы, присущие варианту с применением «round-robin DNS», при использовании IBM's Network Dispatcher отсутствуют, поскольку все запросы клиентов «поступают в адрес» Network Dispatcher, а далее распределяются уже им по обслуживаемых Web-серверам. Кардинального решения проблемы распределения нагрузки между Web-серверами Domino, входящими в состав кластера, следует ожидать только в Domino версии 5.0. В его состав будет входить спецально предназначенная для этих целей задача Internet Cluster Manager (ICM). Эта
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 115
задача устанавливается на одном из серверов-членов кластера, «принимает на себя», подобно IBM's Network Dispatcher, запросы Web-клиентов, и затем, с учетом возможности исполнения запроса (наличия реплик) и реальной загрузки, перенаправляет их задачам HTTP на других серверах-членах кластера. ICM поддерживает запросы как по «обычному» протоколу HTTP, так и по протоколу HTTP с поддержкой SSL. В подтверждение сказанного на Рис. 9.11 дается внешний вид секции ICM из документа Server адресной книги Domino версии 5.0 (Developer Test Build 2).
Рис. 9.11 Внешний вид секции ICM из документа Server адресной книги Domino версии 5.0
© InterTrust Co. Тел. 956-7928
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 117
10. Secure Sockets Layer в Lotus Domino 4.6.1 Материал этой главы поможет вам понять, что такое SSL, как в Domino реализована его поддержка и что необходимо проделать на сервере Domino и в броузере клиента для обеспечения поддержки SSL.
10.1. Основы SSL Фундаментом коммуникаций по Internet является протокол TCP/IP. Поскольку протокол открыт и относительно прост, существует множество людей, хорошо осведомленных во всех его тонкостях. Когда вы устанавливаете соединение с кем-нибудь в Internet, передаваемые между вами пакеты могут быть «перехвачены» на пути их следования третьими лицами, записаны и исследованы. Чтобы получать копии всех пакетов, которыми вы обменивались в течение сеанса, в простейшем случае могут использоваться программы, известные как IP sniffers. Более того, вы даже не знаете наверняка, с кем вы в действительности установили соединение и не искажают ли третьи лица информацию, передаваемую между вами и тем, с кем вы установили соединение. Более подробную информацию по этим вопросам можно найти, например, в главе 4 «Анализ способов нарушения информационной безопасности» из книги «Теория и практика обеспечения информационной безопасности» 1). Однако использование SSL вместе с протоколами прикладного уровня поверх TCP/IP обеспечивает в условиях априорно небезопасной сети приемлемую защиту первого уровня. SSL (Secure Sockets Layer – «слой защищенных сокетов») был первоначально создан компанией Netscape, чтобы обеспечить поверх обычного протокола HTTP дополнительный «слой», включающий аутентификацию клиентом и сервером друг друга на основе сертификатов, шифрование передаваемых по соединению данных и проверку того, что передача осуществляется без искажений. В настоящее время SSL утвержден и становится основным стандартом первого уровня для защиты всех протоколов Internet и трафика прикладных программ, работающих поверх TCP/IP. Его следует понимать как простое, общее и полезное соглашение (спецификацию), которому должны следовать разработчики программного обеспечения, чтобы защитить любое двунаправленное соединение по сети. Отметим, что SSL вовсе не единственный из применяемых стандартов защиты передаваемых по сети данных. Например, в настоящее время в состоянии утверждения находится стандарт SET (Secure Electronic Transaction), возможности которого в мире электронной торговли многие оценивают выше SSL. Рассмотрим основные моменты, позволяющие уяснить принцип функционирования SSL 2). Реализация SSL компании Netscape использует систему шифрования RSA. В этой системе шифрования каждому субъекту (пользователю или серверу) предоставляется пара ключей для шифрования и дешифрирования данных. Пара состоит из открытого ключа (public key) и секретного ключа (private key). Данные, которые зашифрованы открытым ключом, могут быть дешифрированы только секретным ключом. Наоборот, данные, зашифрованные секретным ключом, могут быть дешифрированы только открытым ключом. Обозначим данные, зашифрованные ключом «ключ», как {данные} ключ . Тогда справедливы соотношения
1)
Под ред. П. Д. Зегжды. М.: Издательство агентства «Яхтсмен», - 1996, 192 с.
2)
Более подробное изложение этих вопросов на русском языке имеется, например, в книге Сергея Баричева «Kpиптогpафия без секpетов», электронную версию которой можно попытаться найти по ссылке http://infoart.sinaps.ru/it/talk/crypto/index.htm. Наиболее полную информацию о SSL на английском языке можно найти по ссылкам http://home.netscape.com/info/security-doc.html и http://www.consensus.com/security/ssl-talkfaq.html, а об алгоритме RSA – по ссылке http://www.rsa.com/.
© InterTrust Co. Тел. 956-7928, 956-7929
118
Secure Sockets Layer в Lotus Domino 4.6.1
{ {данные} public-key} private-key = данные { {данные} private-key} public-key = данные Открытый ключ передается владельцем любому желающему его иметь, и, следовательно, известен многим. Секретный ключ, напротив, доступен только его владельцу и никогда не должен передаваться другим. Хотя секретный и открытый ключи находятся в известной математической зависимости, попытка подбора одного ключа при известном другом ключе требует значительной вычислительной работы, причем количество этой работы возрастает экспоненциально в зависимости от используемой длины ключей.
Аутентификация (установление подлинности) Установление подлинности - процесс проверки, позволяющий одному субъекту убедиться в том, что другой субъект именно тот, «кем он представился» первому субъекту. Предположим, что субъект A хочет аутентифицировать субъекта B. B имеет пару ключей – секретный и открытый, и уже сообщил свой открытый ключ субъекту A. Способ, которым B сообщил A свой открытый ключ, мы обсудим ниже. Субъект A генерирует «случайным образом» сообщение и посылает его B: A → B: Произвольное сообщение Приняв это сообщение, B шифрует его своим секретным ключом и возвращает зашифрованную версию A: B → A: {Произвольное сообщение} B-private-key A получает это сообщение и дешифрирует его, используя открытый ключ B, а затем сравнивает полученный результат с первоначально отправленным сообщением: { {Произвольное сообщение} B-private-key } B-public-key =?= Произвольное сообщение Если обнаружено совпадение, А считает, что соединение установлено действительно с B. Любой другой субъект C, представившийся A под именем B, не смог бы пройти такую проверку, поскольку он не знает секретного ключа B.
Постоянная проверка источника принятых данных Функция (алгоритм) хеширования по данным Д произвольной длины вычисляет некоторое значение, обычно, длиной в 128 бит. Будем обозначать это значение digest[Д]. Поскольку такая операция не сохраняет количество информации, очевидно, существует множество данных Д', что digest[Д'] = digest[Д], но Д' ≠ Д. Может показаться, что в качестве алгоритма хеширования можно использовать практически любой алгоритм, например, сумму по модулю 2 каждых очередных 16-и байтов данных. Но для рассматриваемого нами применения подходит лишь такой алгоритм, который гарантирует, что попытка подбора Д' ≠ Д, чтобы digest[Д'] = digest[Д], потребует значительной вычислительной работы. Например, алгоритм MD5, разработанный компанией RSA. В случае «не заслуживающего доверия» соединения необходимо обеспечить, чтобы субъект A, принимая данные от субъекта B, был всегда уверен, что эти данные были переданы именно B, а не некоторым другим субъектом C, «вмешавшимся в разговор». Для этого B «приходится» передавать A «вслед» за данными значение функции хеширования от этих данных, зашифрованное секретным ключом B: B → A: Сообщение + { digest[Сообщение] } B-private-key Тогда A, «зная» открытый ключ B, сможет вычислить значение функции хеширования по принятому сообщению и сравнить это значение со значением функции хеширования, вычисленным B по отправленному сообщению и в зашифрованном виде переданным A:
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 119
digest[Сообщение] =?= { { digest[Сообщение] } B-private-key } B-public-key Если обнаружено совпадение, А считает, что им было принято сообщение от B, причем в точности такое, какое отправлял B. Любой другой субъект C, во-первых, не может создать подобное сообщение, поскольку он не знает секретного ключа B, а во-вторых, не может «незаметно» для A внести изменения в «перехваченное» им «в пути» от B к A сообщение, поскольку подбор Д' ≠ Д с digest[Д'] = digest[Д] потребует значительной вычислительной работы. Описанная методика широко известна как «цифровая подпись». Говорят, что B «подписал» отправленное им сообщение, а A «проверил цифровую подпись B под принятым им сообщением».
Распространение открытых ключей Рассмотренное выше предполагает, что каждый из субъектов уже знает открытый ключ другого. Чтобы решить проблему «первичной передачи» открытого ключа, используется объект, именуемый сертификатом. Каждый из субъектов (A и B) имеет свой сертификат. Сертификат содержит имя своего владельца, его открытый ключ и дополнительную информацию, обычно дату истечения срока действия сертификата. Сертификат имеет также цифровую подпись 3-ей стороны – субъекта, выдавшего этот сертификат. Чтобы проверить «подпись под сертификатом», необходимо заранее знать открытый ключ выдавшего сертификат субъекта. Процесс «первичной передачи» открытого ключа напоминает следующее. A → B: «Передай свой сертификат» B → A: Cертификат-B Получив сертификат субъекта B, субъект A проверяет «подпись под сертификатом», используя открытый ключ выдавшего этот сертификат субъекта. Способ, которым A получает открытый ключ субъекта, выдавшего сертификат B, мы обсудим ниже. Если проверка подписи прошла успешно, A «извлекает» из полученного сертификата имя и открытый ключ B. Затем «диалог» продолжается. A → B: «Докажи это» B → A: «Я действительно B» + { digest[«Я действительно B»] } B-private-key Субъект A проверяет «подпись под» принятым сообщением, используя открытый ключ B. Если проверка успешна, A «считает», что он «уверенно знает» открытый ключ B, а В «знает» свой секретный ключ. Предположим, что другой субъект C, имеющий сертификат субъекта B, «перехватывает» сообщения, передаваемые между A и В, и пытается имитировать поведение B. A → С: «Передай свой сертификат» С → A: Cертификат-B A → С: «Докажи это» С → A: «Я действительно B» + { digest[«Я действительно B»] } ??? Попытка завершится неуспехом, поскольку С не знает секретного ключа B. Однако такая попытка могла быть успешной, если бы С знал секретный ключ B. Поэтому B должен хранить свой секретный ключ «в надежном хранилище» и никогда не передавать его другим субъектам.
Обмен секретной информацией После того, как A аутентифицировал B, он может передавать B информацию в
© InterTrust Co. Тел. 956-7928, 956-7929
120
Secure Sockets Layer в Lotus Domino 4.6.1
зашифрованном виде. Это могло бы происходить следующим образом: A → B: { «секрет» } B-public-key + { digest[{ «секрет» } B-public-key] } B-public-key «Извлечь информацию» из этого сообщения может только субъект В, поскольку только он должен знать свой секретный ключ. После успешной проверки цифровой подписи B выполняет над принятыми им данными операцию {{ «секрет» } B-public-key} B-private-key =«секрет» Однако имеются два мотива, чтобы усовершенствовать этот процесс. Во-первых, в алгоритмах семейства RSA с двумя ключами используют обычно ключи длиной 512 бит, а при таких длинах ключей затраты на шифрование-дешифрирование относительно велики. Вовторых, хотя смена пары «секретный/открытый ключи» и возможна, на практике она выполняется относительно нечасто, например, один раз в год. А это уже срок из разряда теоретически достаточных для подбора «перехватчиком сообщений» C секретного ключа В и дешифрирования переданной A информации. Проблема решается при использовании криптографических алгоритмов с одним и тем же ключом для шифрования и дешифрирования - типа DES, RC4 или IDEA. Во-первых, эти алгоритмы «работают быстрее», а во-вторых, ключ шифрования субъекты могут сгенерировать случайным образом, обменяться им, а затем использовать его только в течении некоторого непродолжительного времени. Обмен ключом шифрования может происходить следующим образом. A выбирает алгоритм шифрования с одним ключом (из числа поддерживаемых А и B), генерирует случайным образом ключ шифрования для этого алгоритма и передает B название алгоритма и ключ. A → B: {RC4,ключ-RC4}B-public-key+{digest[{RC4, ключ-RC4}B-public-key]}B-public-key B → A: «Ok RC4» + {digest[«Ok RC4»]}A-public-key A → B: {«секрет»}ключ-RC4 + {digest[«секрет»]}ключ-RC4 В результате «хакеру» C остается возможность «перехватывать» передаваемую между А и В информацию, «не понимая ее смысла». Попытки же со стороны C «искажать» передаваемую информацию сразу же будут обнаружены субъектом B – для таких сообщений попытка «проверить подпись» закончится неуспешно. Обнаружив вмешательство, В может запросить от А повторную передачу «искаженных» сообщений. Таким образом, C не может получать или изменять передаваемую между А и В информацию, однако может мешать нормальной передаче и даже, искажая все передаваемые сообщения, сделать передачу совершенно невозможной. Самоподписанные сертификаты Самоподписанный сертификат представляет собой сертификат, выданный для субъекта «за подписью» этого же субъекта. Один из примеров самоподписанных сертификатов сертификаты, которые организации, специализирующиеся на выпуске сертификатов для других субъектов (например, VeriSign, Inc.), используют для того, чтобы сообщать свои открытые ключи всем субъектам, которым приходится проверять выданные этими организациями сертификаты. Для субъекта, получившего самоподписанный сертификат, последний означает приблизительно следующее: "Вот тебе сертификат. Я (тот, кто выдал) выдал его и только я могу проверять его непосредственно, ибо «уверенно» знаю свой открытый ключ. Ты же можешь этому сертификату «доверять» (т.е. извлекать «без проверки» из него мой открытый ключ и использовать при проверке других сертификатов, выданных мною) или «не доверять»". Уровень доверия самоподписанному сертификату выбирается его потребителем в соответствии с уровнем доверия к тому пути, которым сертификат был доставлен от издателя к потребителю. Самоподписанный сертификат, переданный лично вам на дискете лицом, представляющим выдавшую сертификат организацию, непосредственно известным вам и заслуживающим вашего доверия, вероятно, тоже заслуживает доверие. Самоподписанный © InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 121
сертификат, которое вы получаете по Internet от, вообще говоря, «неизвестного» субъекта и по «неизвестному» каналу (от него до вас), вообще говоря, не заслуживает доверия.
10.2. Обзор реализации SSL в Domino Пользователи, работающие из клиентов Notes с серверами Notes, имеют и автоматически используют собственные механизмы аутентификации и защиты информации. Эти механизмы появились в Notes за несколько лет до появления первых версий SSL, однако во многом оказались похожими на сегодняшние версии SSL. Однако с сервером Domino можно также работать из самых различных броузеров и почтовых клиентов по стандартным протоколам прикладного уровня поверх TCP/IP: Hyper Text Transfer Protocol (HTTP), Post Office Protocol v. 3 (POP3), Internet Message Access Protocol (IMAP), Lightweight Directory Access Protocol (LDAP), Network News Transport Protocol (NNTP). При работе по этим протоколам без использования SSL аутентификация обычно осуществляется «в форме cleartext» – по запросу сервера пользователь вводит имя и пароль, они передаются серверу в общеизвестном формате name:password с применением способа кодирования символов Base64, а передача данных в ходе сеанса – в незашифрованном виде. В этом случае аутентификация сторон и защита передаваемой информации, которые пользователь Notes считает само собою разумеющимися, почти полностью отсутствуют. Сравнимый с «обычным Notes» уровень безопасности при работе с сервером Domino из броузеров и почтовых клиентов (например, Netscape Navigator, MS Internet Explorer, Netscape Messenger, MS Outlook Express…) можно обеспечить только при работе по вешеупомянутым протоколам прикладного уровня с применением SSL. Первая и основная функция SSL – шифрование передаваемых сообщений. Хакеры могут получать копии всех пакетов, которыми обменивались пользователь и сервер в течение сеанса. Если бы информация передавалась в незашифрованном виде, хакер имел бы возможность исследовать эту информацию. При использовании SSL вся информация после «SSLрукопожатия» передается в зашифрованном виде, так что перехват пакетов не дает возможности «понять» их содержимое. Чтобы гарантировать секретность передаваемых сообщений, совместно используются две различные схемы шифрования: шифрование с применением двух (открытого и секретного) ключей (RSA) и шифрование с одним ключом (обычно, RC4). При инициализации сеанса в процессе «SSL-рукопожатия», стороны, используя схему шифрования с двумя ключами, договариваются об алгоритме шифрования с одним ключем и его ключе, которыми и будет шифроваться последующая часть трафика между SSL-сервером и SSL-клиентом. Во-вторых, SSL гарантирует, что сообщения не были изменены каким-либо способом в процессе их передачи между сервером и клиентом. Чтобы обеспечить это, SSL-сервер и SSLклиент используют механизм цифровой подписи. Если в ходе сеанса обнаружено «поврежденное» или «непонятное» сообщение, предполагается, что имело место вмешательство. Постоянно проверяя целостность сообщений, SSL-сервер и SSL-клиент способны поддерживается целостность сеанса и гарантировать непрерывную безопасную передачу. Последняя и наиболее важная функция SSL - взаимное установление подлинности (аутентификация). Это процесс, в ходе которого клиент и сервер могут убедиться в подлинности друг друга. Процесс включает обмен сертификатами стандарта X. 509 и проверку этих сертификатов.
«SSL-рукопожатие» (SSL Handshake) SSL в меру возможности «скрывает свое присутствие» от конечного пользователя. Обычно, пользователь броузера просто «переходит по ссылке» на необходимую ему HTML-страницу, а при этом броузер автоматически соединяется по протоколу HTTP с поддержкой SSL (HTTPS) с
© InterTrust Co. Тел. 956-7928, 956-7929
122
Secure Sockets Layer в Lotus Domino 4.6.1
поддерживающим SSL сервером. Обычно HTTP-серверы, поддерживающие SSL, открывают такое соединение не по порту для обычных HTTP-запросов (по умолчанию порт 80), а по другому порту (по умолчанию порт 443). Другим протоколам для использования с SSL тоже назначены соответствующие порты по умолчанию. Когда прикладная программа пользователя устанавливает соединение с сервером, начинается процедура «SSL-рукопожатия», по завершении которой открывается SSL-сессия. С этого момента и до тех пор, пока SSL-сессия поддерживается, весь трафик между пользователем и сервером шифруется и выполняются проверки целостности передаваемых пакетов. На одну SSL-сессию «SSL-рукопожатие» выполняется только один раз. «SSL-рукопожатие» выполняется в три этапа.
•
•
•
Сначала, пользователь и сервер (или сервер и сервер) обмениваются своими сертификатами X.509. Сертификаты проверяются как на предмет возможной подделки цифровой подписи выдавшего их «третьего лица», так и на предмет даты окончания срока их действия. После этого каждая из сторон «знает» открытый ключ другой. Затем клиент и сервер обмениваются случайными сообщениями с применением шифрования по схеме с двумя ключами, что позволяет им убедиться, что каждая из сторон «знает» свой секретный ключ. Если все прошло успешно, «рукопожатие» продолжается, но с этого момента передаваемые между сторонами сообщения шифруются по схеме с двумя ключами. Если же что-то было некорректно, соединение разрывается. Клиент и сервер «договариваются» о функции хеширования, и с этого момента каждая сторона, передавая сообщение, «подписывает» его, а другая сторона, приняв сообщение, «проверяет стоящую под ним» цифровую подпись. Затем клиент и сервер «договариваются» о алгоритме шифрования с одним ключом, который будет использоваться в открываемой сессии. Сначала сервер «просит», чтобы броузер клиента сообщил список всех доступных ему алгоритмов шифрования с одним ключом. Затем сервер выбирает «самый сильный» алгоритм шифрования с одним ключом из тех, которые поддерживаются сервером и клиентом. Однако, по опыту автора, при использовании International Release Domino этим «самым сильным» алгоритмом всегда оказывается RC4 с ключами по 40 бит. На последнем этапе «рукопожатия» одна из сторон (обычно, сервер) случайным образом генерирует ключ, который должен использоваться для шифрования сообщений по схеме с одним ключом, и передает его другой стороне. В данный момент каждая сторона «имеет в своих руках» по четыре ключа: свои секретный и открытый ключи, открытый ключ другой стороны и ключ шифрования по схеме с одним ключом, который будет использоваться в течении открываемой сессии. С этого момента вся передаваемая между сторонами информация шифруется по схеме с одним ключом.
Как реализация SSL встроена в Domino Реализация SSL встроена в архитектуру Domino на уровне сетевой абстракции. Поэтому один и тот же набор подпрограмм отвечает в Domino за реализацию SSL как на разных платформах, так и для разных типов сетей. Кроме того, подпрограммы, реализующие SSL в Domino, «знают только», что по данному порту SSL должен поддерживаться, но «не знают», для какого именно протокола прикладного уровня с поддержкой SSL (HTTP, IMAP…) данный порт используется. Все это существенно сокращает затраты на сопровождение кода Domino SSL и гарантирует его одинаковые функциональные возможности на разных платформах. Подпрограммы, реализующие SSL в Domino, в основном «привязаны» к подпрограммам отправки-получения сообщений сетевого уровня. Основную работу по реализации SSL выполняет подпрограмма ICT. После завершения первой фазы «SSL-рукопожатия» эта подпрограмма «активизируется на перехват» и начинает «перехватывать» каждую операцию отправки-получения сообщений. При отправке сообщения ICT выполняет над подготовленным к отправке сообщением соответствующие алгоритмы шифрования и цифровой подписи, а затем передает результат обработки подпрограммам отправки сетевого уровня. Для полученных от
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 123
подпрограмм сетевого уровня «входящих» зашифрованных и подписанных сообщений ICT выполняет соответствующие алгоритмы расшифровки и проверки подписи. По завершении SSL-сессии подпрограмма ICT прекращает «перехват» операций отправки-получения сообщений и освобождает «захваченные» ею память и другие ресурсы.
10.3. Сертификаты X.509, Certificate Authority, Trusted Roots и KeyRing-файлы Cертификаты стандарта X.509 содержат:
• • • •
«Различаемое» (distinguished) имя владельца сертификата. Открытый ключ владельца сертификата. Он необходим для осуществления шифрования по схеме с двумя ключами. Прочее наполнение (серийный номер; дата, до наступления которой сертификат имеет силу; название организации, выдавшей сертификат...) Цифровая подпись (fingerprint) по имеющейся в сертификате информации «от имени» выдавшей сертификат организации, которую обобщенно называют Certificate Authority.
Рис. 10.1 Так выглядит в Netscape Navigator сертификат пользователя, выпущенный VeriSign Class 1 CA (из меню Communicator - Security Info – Certificates\Yours - View) Certificate Authority (CA) – 3-я сторона, выдающая сертификаты для пользователей и серверов по их запросам. Она может быть «общеизвестной» (например, VeriSign, Inc.) или «внутрикорпоративной» (например, любая организация, использующая Notes Domino). Роль CA состоит в расширении взаимного доверия. Говоря упрощенно, CA выступает как посредник (третье лицо) между двумя сторонами, чтобы стало возможным проверить, не пытается ли одна из сторон предоставить другой «поддельный» сертификат. Подробнее же происходит следующий процесс.
• • •
CA «подписывает» сертификат (будем предполагать, ваш), используя для этого свой (CA) секретный ключ. На первом этапе «SSL-рукопожатия» вы посылаете мне ваш сертификат. Я использую открытый ключ CA, сообщенный мне CA, «подписавшей» ваш сертификат, чтобы проверить, что ваш сертификат был действительно выдан ими и что в него не было внесено изменений с тех тор, как этот сертификат был выдан. Чтобы сделать это, я должен быть способен найти открытый ключ для вашей CA в своем «хранилище ключей».
© InterTrust Co. Тел. 956-7928, 956-7929
124
Secure Sockets Layer в Lotus Domino 4.6.1
Для того, чтобы пользователь и сервер могли взаимно проверить сертификаты друг друга, каждый из них, проверяя сертификат другого, должен найти в своем «хранилище ключей» открытый ключ той CA, которая этот сертификат выпустила, т.е. «подписала». Открытый ключ CA содержится в «хранилище ключей» «не сам по себе», а в составе сертификата, выпущенного этой CA «для своего имени за своей же подписью» - так называемого «самоподписанного» сертификата. Причем просто факта наличия самоподписанного сертификата CA в «хранилище ключей» обычно недостаточно – необходимо, чтобы владелец «хранилища ключей» явным образом «заявил о своем доверии этой CA», т.е. о том, что он уверен, что открытый ключ этой CA именно таков, как указано в самоподписанном сертификате этой CA, находящемся в «хранилище ключей» этого владельца. В зависимости от того, находитесь ли вы в среде Netscape Navigator, MS Internet Explorer или клиента Notes, запущенного на сервере Notes, такое «заявление о доверии CA» выглядит, называется и настраивается немного по разному. В среде клиента Notes, запущенного на сервере Notes, администратор сервера выбирает самоподписанные сертификаты некоторых CA в качестве "доверяемых корней" ("Trusted Roots").
Рис. 10.2 Самоподписанные сертификаты CA, которые администратор сервера Notes выбрал в качестве Trusted Roots Пользователь Netscape Navigator автоматически «доверяет» всем имеющимся в его «хранилище» самоподписанным сертификатам CA, но имеет возможность удалить из «хранилища» самоподписанные сертификаты некоторых CA или добавить в него новые.
Рис. 10.3 Список CA, сертификаты которых «разрешил проверять» пользователь Netscape Navigator (из меню Communicator – Security Info – Certificates\Signers) © InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 125
Пользователь MS Internet Explorer «отмечает галочкой» самоподписанные сертификаты тех CA, «которым он доверяет».
Рис. 10.4 Список CA, сертификаты которых «разрешил проверять» пользователь MS Internet Explorer Но суть «заявления о доверии» везде одна и та же – сторона «разрешает» своему программному обеспечению без всякой проверки извлекать открытый ключ CA из самоподписанного сертификата данной CA в своем «хранилище ключей» и использовать этот открытый ключ при проверке сертификата, выпущенного данной CA для другой стороны.
Рис. 10.5 Так выглядит самоподписанный сертификат VeriSign Class 1 CA в среде Netscape Navigator Заметим, что самоподписанные сертификаты «общеизвестных» CA обычно изготавливаются этими CA заблаговременно, передаются компаниям-разработчикам программного обеспечения, и уже компаниями-разработчиками «включаются» в производимое ими программное обеспечение. Но в то же время клиент обычно имеет возможность обратиться непосредственно на Web-сервер компании, выполняющей роль CA, получить с него самоподписанный сертификат этой CA и «поместить» его в свое «хранилище ключей».
© InterTrust Co. Тел. 956-7928, 956-7929
126
Secure Sockets Layer в Lotus Domino 4.6.1
В качестве «хранилища ключей» обычно выступает KeyRing-файл (Key Ring File). Наиболее подходящие по смыслу в нашем контексте переводы термина «Key Ring» - «кольцо с ключами», «связка ключей», «хранилище ключей». KeyRing-файл представляет собой двоичный файл, дополнительно защищенный паролем. Злоумышленнику недостаточно просто скопировать этот файл – чтобы воспользоваться файлом, необходимо знать его пароль. В «обычном» Notes аналогом KeyRing-файла является ID-файл. KeyRing-файлы используются в Domino в качестве контейнеров для хранения:
• • •
открытых и секретных ключей владельца файла; сертификатов для владельца файла, «подписанных» CA; самоподписанных сертификатов для Trusted Root CA – тех, которые «подписали» сертификаты владельца файла и иных, которым владелец файла «доверяет».
Каждый субъект, поддерживающий SSL, имеет свой KeyRing-файл. Сервер Domino, поддерживающий SSL, имеет KeyRing-файл сервера. Cервер Domino, выполняющий функции внутрикорпоративной CA, имеет два KeyRing-файла: для Certificate Authority и для сервера. Клиент броузера тоже хранит свои ключи и сертификаты в KeyRing-файле, только этот файл «управляется» специфическим для броузера способом.
10.4. Обеспечение поддержки SSL серверами Domino Процесс начинается созданием необходимых KeyRing-файлов: для «внутрикорпоративной» Certificate Authority и для серверов Domino. В качестве сервера Certificate Authority выбирается один из серверов, на котором функционирует задача HTTP. На этом сервере создается база Certificate Authority CERTCA.NSF. Оперируя в этой базе, можно создать KeyRing-файл для «внутрикорпоративной» Certificate Authority. Этот KeyRing-файл (обычно он имеет имя CAKey.kyr) будет помещен в каталог данных сервера, а все «управление» файлом осуществляется из базы CERTCA.NSF. С этого момента становится возможным создать KeyRing-файл для этого сервера. Этот KeyRingфайл (на Рис. 10.6 он имеет имя KeyFile1.kyr) будет помещен в каталог данных сервера, а все «управление» файлом осуществляется из базы Server Certificate Administration - CERTSRV.NSF. KeyRing-файл сервера «напрямую» необходим серверным задачам (например, HTTP) для поддержки SSL. Сервер Certificate Authority
HTTP
Сервер 2
Сервер 3
HTTP
IMAP
CERTCA.NSF
CERTSRV.NSF
CERTSRV.NSF
CERTSRV.NSF
CAKey.kyr
KeyFile1.kyr
KeyFile2.kyr
KeyFile3.kyr
Рис. 10.6 Создание KeyRing-файлов и управление ими
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 127
Все последующие «текущие» работы по поддержке SSL - выпуск сертификатов для клиентов и других серверов, передача самоподписанного сертификата CA всем нуждающимся и т.п. - выполняются в базе CERTCA.NSF администратором «внутрикорпоративной» Certificate Authority по запросам от клиентов или администраторов других серверов. На других серверах домена, где функционирует задача HTTP или другие задачи, допускающие работу с применением SSL (POP3, IMAP, LDAP, NNTP…), создается только база Server Certificate Administration - CERTSRV.NSF. Оперируя в этой базе, можно создать KeyRing-файл для данного сервера. Этот KeyRing-файл (на Рис. 10.6 он имеет имя KeyFileX.kyr) будет помещен в каталог данных сервера и станет «напрямую» использоваться его серверными задачами для поддержки SSL.
10.4.1. База Certificate Authority Выберите сервер для этой роли и создайте на нем базу CERTCA.NSF - Certificate Authority по шаблону CCA461.NTF.
Рис. 10.7 Создание базы Certificate Authority из клиента, запущенного на сервере Notes В списке управления доступом созданной базы «назначьте» себя и тех лиц, которые будут выполнять функции администраторов CA, на роль CAPrivlegedUser. Остается выполнить три действия: создать KeyRing-файл и самоподписанный сертификат для Certificate Authority, «заполнить профиль» и создать KeyRing-файл для сервера Domino. Все прочие операции с данной базой будут носить «текущий» характер.
Создание KeyRing-файла и самоподписанного сертификата для Certificate Authority KeyRing-файл для CA содержит секретный и открытый ключи и самоподписанный сертификат этой CA. Файл необходим, чтобы было возможным «подписывать» сертификаты для ваших серверов Domino и клиентов «от имени» CA. Кроме того, копия самоподписанного сертификата CA помещается в текстовое поле в документе, создаваемом по форме CACert в базе CERTCA.NSF. Этот документ необходим, чтобы удобно экспортировать из него самоподписанный сертификат CA любому желающему «установить» этот сертификат в качестве Trusted Root. Из клиента Notes, запущенного на компьютере сервера, откройте локально базу Certificate Authority и выберите в навигаторе пункт "1. Create Certificate Authority Key Ring & Certificate".
© InterTrust Co. Тел. 956-7928, 956-7929
128
Secure Sockets Layer в Lotus Domino 4.6.1
Рис. 10.8 Навигатор базы Certificate Authority Заполните появившуюся форму.
Рис. 10.9 Форма для создания KeyRing-файла CA В поле Key Ring File Name укажите имя для создаваемого KeyRing-файла. По умолчанию предлагается имя CAKEY.KYR. Если в поле не указан полный путь, файл создается в каталоге данных сервера. Обратите внимание, что в одной базе Certificate Authority может быть создан только один такой файл - при попытке создать в базе второй файл вы получите соответствующее предупреждение (Рис. 10.10). В поле Key Ring Password задайте пароль, необходимый для использования этого файла (не менее 6 символов). Информация, которую вы введете в следующих полях, определяет различаемое (distinguished) имя вашей CA.
•
Common Name – общее (common) имя CA, например, InterTrustCorp.
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 129
• • • • •
Organizational Unit (необязательно) – оргединица, в состав которой входит CA. Organization - название вашей организации, например, InterTrust Co. City or Locality (необязательно) – местоположение CA (например, город). State or Province – штат или провинция (область). Country – двухсимвольный код страны.
Рис. 10.10 В одной базе CERTCA.NSF можно создать только один KeyRing-файл для CA По заполнении полей в форме нажмите кнопку Create Certificate Authority Key Ring, затем кнопку Ok в окне-подтверждении.
Рис. 10.11 Подтверждение о создании KeyRing-файла По завершении операции рекомендуется сделать копию созданного KeyRing-файла CA и сохранить ее в безопасном месте. К оригиналу файла должны иметь доступ (знать пароль файла) только лица, выполняющие функции администраторов CA.
Заполнение профиля Certificate Authority Выбрав в навигаторе пункт "2. Configure Certificate Authority Profile", вы получите форму (Рис. 10.12), в которой необходимо уточнить местоположение KeyRing-файла (чтобы не
© InterTrust Co. Тел. 956-7928, 956-7929
130
Secure Sockets Layer в Lotus Domino 4.6.1
вводить его при каждой операции «текущего» характера) и задать имя хоста, по которому доступен ваш сервер Domino (используется при генерации URL «на документы» в данной базе).
Рис. 10.12 Форма «Профиль CA»
Создание KeyRing-файла для сервера Domino, одновременно выполняющего функцию сервера Certificate Authority Выбрав в навигаторе пункт «3. Create Server Key Ring & Certificate», вы получите следующую форму.
Рис. 10.13 Форма для создания KeyRing-файла сервера в базе CERTCA.NSF
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 131
В поле Key Ring File Name задайте имя создаваемого файла, включая путь. По умолчанию предлагается имя KeyFile.KYR. В поле Key Ring Password укажите пароль, который должен будет использоваться для доступа к этому файлу (не менее 6 символов). В поле CA Certificate Label введите общее (common) имя вашей CA. В поле Common Name следует задать имя хоста, по которому доступен этот сервер Domino. Обратите внимание, что SSL может поддерживаться вашим сервером Domino только при обращении к нему из броузера по заданному в этом поле имени хоста. К серверу, сконфигурированному для поддержки нескольких виртуальных серверов Domino, обращение с использованием SSL возможно только по одному имени хоста. Остальные поля подобны соответствующим полям в рассмотренной ранее форме для создания KeyRing-файла CA. Остается нажать кнопку Create Server Key Ring, ввести в появившемся диалоговом окне пароль для обращения к KeyRing-файлу вашей CA и нажать кнопку Ok в окне-подтверждении о создании KeyRing-файла сервера.
Рис. 10.14 Подтверждение о создании KeyRing-файла сервера Созданный KeyRing-файл содержит все, что необходимо:
• • •
секретный и открытый ключи сервера, сертификат для этого сервера, «подписанный» вашей CA, самоподписанные сертификаты вашей CA и ряда «общеизвестных» CA, уже установленные как Trusted Root.
После этого вам, по-сути дела, остается лишь выполнить действия по завершению настройки SSL на данном сервере Domino (см. 10.4.3). Отметим, что в Domino версии 4.6 при выборе в навигаторе аналогичного «3. Create Server Key Ring & Certificate» пункта выдавалось только описание последовательности действий для создания KeyRing-файла сервера. Выполнять же эти действия приходилось в базе CERTSRV.NSF – Server Certificate Administration.
Смена пароля и анализ содержимого KeyRing-файла Certificate Authority Выбрав в навигаторе базы Certificate Authority пункт View Certificate Authority Key Ring, можно «перечитать» в базу информацию из KeyRing-файла (кнопка Display CA Key Ring), сменить пароль KeyRing-файла (кнопка Change CA Key Ring Password), и просмотреть имеющийся в нем самоподписанный сертификат «как документ» (в категории CA Certificate).
Доступ к базе Certificate Authority через броузер При обращении к базе Certificate Authority через броузер клиенты и администраторы серверов Notes могут выполнить следующие операции:
• •
Request Server Certificate - создание запроса на получение подписанного сертификата для сервера, Pick Up Server Certificate - вставка подписанного сертификата в KeyRing-файл сервера, © InterTrust Co. Тел. 956-7928, 956-7929
132
• • • •
Secure Sockets Layer в Lotus Domino 4.6.1
Accept This Authority In Your Server/Browser - вставка самоподписанного сертификата CA в KeyRing-файл сервера или в броузер клиента в качестве Trusted Root, Request Client Certificate - создание запроса на получение подписанного сертификата для броузера, Pick Up Client Certificate - вставка подписанного «клиентского» сертификата в броузер, Register Browser Certificate In Address Book - регистрация сертификата броузера в адресной книге сервера.
Рис. 10.15 База Certificate Authority в окне броузера
10.4.2. База Server Certificate Administration Прежде всего убедитесь в наличии на сервере базы CERTSRV.NSF – Server Certificate Administration. Эта база автоматически создается при установке сервера Domino: в версии 4.6 по шаблону CERTSRV.NTF, а в версии 4.6.1 - по шаблону CSRV461.NTF. Однако ваш сервер «мог претерперь» целую серию обновлений версий… Так что, если база CERTSRV.NSF по каким-то причинам отсутствует, просто создайте новую шаблону CSRV461.NTF.
Рис. 10.16 Создание базы Server Certificate Admin из клиента, запущенного на сервере Notes © InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 133
Далее возможны два случая.
•
•
Если KeyRing-файл для вашего сервера уже подготовлен, по-видимому, база будет использоваться вами только для анализа содержимого KeyRing-файла сервера, управления «доверием» самоподписанным сертификатам и смены пароля KeyRing-файла. Рассмотрите ниже только эти возможности базы и переходите к 10.4.3. Маловероятно, что в этом случае вам понадобится «весь функционал» базы CERTSRV.NSF. Если же KeyRing-файл для вашего сервера отсутствует, вам придется познать все возможности базы CERTSRV.NSF. Предстоит выполнить довольно утомительную цепочку действий по созданию KeyRing-файл для сервера: создать KeyRing-файл с «неподписанным» сертификатом, создать запрос на получение подписанного сертификата от CA, установить самоподписанный сертификат CA в качестве Trusted Root, дождаться, пока администратор CA создаст «подписанный» сертификат для вашего сервера, и, наконец, поместить этот сертификат KeyRing-файл вашего сервера. Без всего этого действительно никак не обойтись по крайней мере в двух случаях: если ваш сервер Domino версии 4.6, но не 4.6.1, или если сервер должен получить сертификат от «не Domino» Certificate Authority.
Смена паролей, анализ содержимого KeyRing-файлов и управление «доверием» самоподписанным сертификатам из базы Server Certificate Administration Выбрав в навигаторе базы Server Certificate Administration пункт View & Edit Key Rings, можно:
• • •
Выбрать KeyRing-файл для смены пароля или изучения его содержимого (кнопка Select Key Ring to Display). Изменить пароль для доступа к выбранному KeyRing-файлу (кнопка Change Key Ring Password). Изучить содержимое выбранного KeyRing-файла: • Документы в категории Site Categories соответствуют имеющиеся в KeyRing-файле сертификатам. • Документы в категории Certificate Authorites соответствуют имеющимся в KeyRingфайле «самоподписанным» сертификатам. Если такой сертификат установлен как Trusted Root, открыв соответствующий ему документ, вы обнаружите в документе кнопку Do Not Trust This Certificate, нажатием которой можно «лишить сертификат доверия». Напротив, если сертификат не установлен как Trusted Root, открыв соответствующий ему документ, вы обнаружите в последнем кнопку Trust This Certificate, нажатием которой можно «вернуть доверие сертификату».
Шаг 1. Создание KeyRing-файла сервера с «неподписанным» сертификатом Для создания KeyRing-файла сервера в навигаторе базы Server Certificate Administration выберите пункт «1. Create KeyRing» (Рис. 10.17). Заполните появившуюся форму (Рис. 10.18). В поле Key Ring File Name задайте имя создаваемого файла, включая путь. По умолчанию предлагается имя KeyFile.KYR. В поле Key Ring Password укажите пароль, который должен будет использоваться для доступа к этому файлу (не менее 6 символов). В поле Common Name следует задать имя хоста, по которому доступен этот сервер Domino. Обратите внимание, что SSL может поддерживаться вашим сервером Domino только при обращении к нему из броузера по заданному в этом поле имени хоста. К серверу, сконфигурированному для поддержки нескольких виртуальных серверов Domino, обращение с использованием SSL возможно только по одному имени хоста. Остальные поля подобны соответствующим полям в рассмотренной ранее форме для создания KeyRing-файла CA.
© InterTrust Co. Тел. 956-7928, 956-7929
134
Secure Sockets Layer в Lotus Domino 4.6.1
Рис. 10.17 Навигатор базы Server Certificate Administration
Рис. 10.18 Форма для создания KeyRing-файла сервера После нажатия кнопки Create Key Ring появится диалоговое окно, подтверждающее создание файла и поясняющее следующий шаг – создание запроса на получение сертификата от CA.
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 135
Рис. 10.19 Подтверждение о создании KeyRing-файла сервера Созданный KeyRing-файл содержит секретный и открытый ключи сервера, «неподписанный» сертификат для этого сервера и достаточно большое количество самоподписанных сертификатов «общеизвестных» CA, уже установленных как Trusted Root. Поскольку сертификат сервера еще «не подписан», он пока и не может быть никем «проверен». Поэтому все последующие шаги направлены на получение «подписи под этим сертификатом от имени» какой-либо CA. «Подписать» сертификат сервера может как «общеизвестная» CA (однако обычно это влечет денежные расходы), так и ваша «внутрикорпоративная» CA.
Шаг 2. Запрос на получение подписанного сертификата от CA Из навигатора в базе Server Certificate Administration выберите пункт «2. Create Certificate Request». В появившейся форме введите имя и пароль для KeyRing-файла сервера, а так же способ передачи запроса на сертификат: либо «вставкой» через буфер обмена в форму в базе или на Web-сервере Certificate Authority, либо «отправкой по почте».
Рис. 10.20 Форма для создания запроса на получение сертификата с передачей через буфер обмена в форму в базе Certificate Authority © InterTrust Co. Тел. 956-7928, 956-7929
136
Secure Sockets Layer в Lotus Domino 4.6.1
Если была выбрана передача через буфер обмена, после нажатия кнопки Create Certificate Request появится диалоговое окно, в котором необходимо «выделить» запрос на сертификат и скопировать его в буфер обмена.
Рис. 10.21 Запрос на сертификат в формате PKCS копируется в буфер обмена Обратите внимание, что запрос на сертификат создается в стандартном формате PKCS (Public Key Cryptography Standards), который распознается как Domino, так и большинством других известных CA. Способ создания запроса «вставкой в поле формы на Web-сервере CA» тоже довольно распространен. Затем нужно открыть базу Certificate Authority на сервере CA (из клиента Notes или через броузер) и, выбрав в ее «главном» навигаторе Submit Server Certificate Request (из клиента Notes) или Request Server Certificate (через броузер), создать в ней документ-запрос (Рис. 10.22 Рис. 10.23).
Рис. 10.22 «Голова» формы запроса на сертификат в базе Certificate Authority © InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 137
Рис. 10.23 «Хвост» формы запроса на сертификат в базе Certificate Authority В создаваемом документе в поле Certificate необходимо вставить из буфера обмена запрос на сертификат в формате PKCS, а так же заполнить остальные поля информацией об авторе запроса. После нажатия кнопки вы получите диалоговое окно - подтверждение о создании запроса.
Рис. 10.24 Подтверждение о создании запроса на сертификат в базе Certificate Authority При передаче запроса на сертификат «по почте» в форме базы базе Server Certificate Administration «появятся» дополнительные поля, в которых потребуется ввести адрес CA, куда отправляется запрос (обычно, адрес администратора этой CA), а так же свой адрес для получения «ответа» и информацию о себе.
Рис. 10.25 Фрагмент формы для создания запроса на получение сертификата с передачей по почте администратору CA © InterTrust Co. Тел. 956-7928, 956-7929
138
Secure Sockets Layer в Lotus Domino 4.6.1
После нажатия кнопки Create Certificate Request появится окно-подтверждение, а в указанный в поле CA’s E-Mail Address адрес будет отправлено письмо с запросом на сертификат в формате PKCS.
Рис. 10.26 Подтверждение об отправке почтой запроса на сертификат Администратор CA получит письмо с запросом (Рис. 10.27) на сертификат, и ему придется создать по полученному письму в базе Certificate Authority такой же документ, который бы вы создали сами при передаче запроса в базу Certificate Authority «методом вставки в поле формы через буфер обмена».
Рис. 10.27 Письмо с запросом на сертификат
Шаг 3. Установка самоподписанного сертификата CA в качестве Trusted Root Просмотрите список Trusted Root в KeyRing-файле сервера (Рис. 10.2). Если необходимая CA в нем отсутствует, обратитесь на Web-сервер этой CA и получите с него самоподписанный
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 139
сертификат этой CA. В большинстве случаев его можно получить в виде файла или скопировать в буфер обмена. Затем в навигаторе базы Server Certificate Administration выберите пункт «3. Install Trusted Root Certificate into Key Ring». Введите в появившейся форме (Рис. 10.28) имя вашего KeyRingфайла и пароль для доступа к нему. Поле Certificate Label не должно оставаться пустым – в него «для идентификации сертификата» в KeyRing-файле нужно поместить общее (common) имя CA. Если самоподписанный сертификат уже скопирован в ваш буфер обмена, выберите Clipboard в поле Certificate Source и вставьте сертификат в следующее поле. Если же сертификат получен в виде файла, выберите File в поле Certificate Source и укажите в поле File Name имя этого файла.
Рис. 10.28 Форма для установки самоподписанного сертификата CA как Trusted Root Нажмите кнопку Merge Trusted Root Certificate into Key Ring и затем дважды Ok.
Рис. 10.29 Информация о самоподписанном сертификате CA, устанавливаемом в качестве Trusted Root © InterTrust Co. Тел. 956-7928, 956-7929
140
Secure Sockets Layer в Lotus Domino 4.6.1
Рис. 10.30 Подтверждение об установке сертификата в качестве Trusted Root
Шаг 4. Администратор CA создает «подписанный» сертификат Следующий шаг выполняется администратором CA по получении запроса на сертификат в стандартном формате PKCS. Если это «внутрикорпоративная» CA в базе Certificate Authority на сервере Domino, то, как будут выглядеть действия администратора CA, описывается ниже. Если же это CA «иной природы», сохранится только семантика выполняемых действий, внешний же вид, скорее всего, будет совершенно другим. Запрос «обнаруживается» администратором CA в виде базы Certificate Authority, открываемом из навигатора выбором в левой части «Server Certificate Requests». При этом кнопками на полосе вида можно просмотреть запросы, ожидающие выпуска сертификата (Certificate Requests\Waiting for Approval), запросы, на которые уже был выпущен сертификат (Certificate Requests\Approved for Pickup), и запросы, в выпуске сертификатов на которые было отказано (Certificate Requests\Denied). Запрос, ожидающий выпуска сертификата, «как документ» выглядит примерно следующим образом.
Рис. 10.31 Администратор CA «подписывает» сертификат © InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 141
Если администратор CA согласен с запросом, то после ввода пароля для KeyRing-файла CA и нажатия кнопки Approve необходимый сертификат будет выпущен. Если была выбрана опция Send a notification email to the requestor, то лицо, запросившее сертификат, получит уведомление почтой. Обратите внимание, что в этом письме-уведомлении содержится «ссылка», указывающая на документ в базе Certificate Authority, из которого нужно «извлечь уже подписанный» сертификат и «поместить» его в KeyRing-файл сервера.
Рис. 10.32 Лицо, запросившее сертификат, получает уведомление о его выпуске
Шаг 5. «Помещение» подписанного сертификата в KeyRing-файл сервера После того, как администратор CA выпустил («подписал») сертификат для вашего сервера, остается поместить этот сертификат в KeyRing-файл сервера. Документ, содержащий сертификат, можно найти в базе Certificate Authority либо из броузера обращением по ссылке из письма, либо выбором из броузера в «главном» навигаторе базы Certificate Authority пункта Pick Up Certificate с последующим вводом идентификатора (Pickup ID) необходимого сертификата. Из этого документа администратор сервера должен получить «подписанный» сертификат либо копированием в буфер обмена, либо как присоединенный файл.
Рис. 10.33 Форма для «помещения» подписанного сертификата в KeyRing-файл сервера © InterTrust Co. Тел. 956-7928, 956-7929
142
Secure Sockets Layer в Lotus Domino 4.6.1
Затем в базе Server Certificate Administration необходимо выбрать в навигаторе пункт «4. Install Certificate into Key Ring». В появившейся форме (Рис. 10.33) следует указать местоположение и пароль вашего KeyRing-файла, а в поле Certificate Source - способ передачи «подписанного» сертификата:
• •
Clipboard – вставка сертификата из буфера обмена в следующее поле, File – ввод имени файла с сертификатом в поле File Name. Остается нажать кнопку Merge Certificate into Key Ring и затем дважды Ok.
Рис. 10.34 Информация о подписанном сертификате, помещаемом в KeyRing-файл сервера
Рис. 10.35 Подтверждение о добавлении сертификата в KeyRing-файл сервера
10.4.3. Настройка SSL на сервере Domino Нам остается «разрешить поддержку» SSL сервером Notes в его документе Server, обеспечить клиентам необходимый доступ к базам, находящимся на сервере, и «вынудить» клиентов пользоваться SSL. Cервер Domino может поддерживать SSL в двух вариантах.
•
Без аутентификации клиента по сертификату X.509. Обеспечивается шифрование и проверка передаваемой между клиентом и сервером информации, выполняется аутентификация сервера клиентом по сертификату сервера, но не выполняется аутентификация клиента сервером по сертификату клиента. При выборе этого варианта: • сервер должен иметь сертификат от «внутрикорпоративной» или внешней CA; • клиент должен иметь сертификат от «внутрикорпоративной» или внешней CA и установить самоподписанный сертификат CA сервера как свой Trusted Root;
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 143
• •
если для клиента создан документ Person с именем и Internet-паролем, сервер может выполнять аутентификацию клиента, но не по его сертификату X.509, а по вводимым клиентом имени и паролю (Name & Password).
С аутентификацией клиента и сервера по сертификатам X.509. В дополнение к предыдущему варианту выполняется и аутентификация клиента сервером по сертификату X.509 клиента. При выборе этого варианта: • сервер должен иметь сертификат от «внутрикорпоративной» или внешней CA; • клиент должен иметь сертификат от «внутрикорпоративной» или внешней CA и установить самоподписанный сертификат CA сервера как свой Trusted Root; • на сервере самоподписанный сертификат CA клиента должен быть установлен как Trusted Root; • для клиента должен иметься документ Person, содержащий его сертификат X.509.
Если вы выбрали вариант «без аутентификации клиента по сертификату X.509», обеспечьте правильную информацию в следующих полях из секции Internet Port and Security Configuration документа Server.
• •
SSL key file – KeyRing-файл сервера. SSL protocol version (только для задач NNTP, IMAP, POP3, LDAP) – версия SSL. • V2.0 only – разрешены только соединения с использованием SSL 2.0. • V3.0 handshake – предпринимается попытка установить соединение с использованием SSL 3.0. Если SSL 3.0 handshake заканчивается неудачей, но клиент поддерживает SSL 2.0, предпринимается попытка установить соединение с использованием SSL 2.0. • V3.0 only – разрешены только соединения с использованием SSL 3.0. • V3.0 and V2.0 handshake - предпринимается попытка установить соединение с использованием SSL 3.0, но вначале выполняется SSL 2.0 handshake.
•
•
Negotiated (по умолчанию) - предпринимается попытка установить соединение с использованием SSL 3.0. При неуспехе предпринимается попытка установить соединение с использованием SSL 2.0. Пока не возникают проблемы установления соединения между клиентом и сервером из-за несовместимых версий SSL, рекомендуется выбирать эту установку. Accept expires SSL certificates – должна (Yes) или не должна (No) игнорироваться дата истечения срока действия сертификата.
Далее в секции Internet Port and Security Configuration располагается таблица, состоящая из двух подтаблиц. «Верхняя» подтаблица содержит настройки для обычных (без применения SSL) портов TCP/IP разных задач, а «нижняя» – для портов TCP/IP с применением SSL. Естественно, что настройки в обоих подтаблицах должны быть согласованы – ситуацию на Рис. 10.36, когда к серверу Domino возможен доступ как по протоколу HTTP (без применения SSL), так и по протоколу HTTPS (с применением SSL), скорее всего следует считать «проколом в защите». Перейдем к заполнению «нижней» подтаблицы.
• • • •
В полях строки SSL port number при необходимости можно изменить используемые по умолчанию номера портов для необходимых вам задач. В полях строки SSL port status выберите Enabled для необходимых вам задач. В полях строки Client certificate выберите No для необходимых вам задач. Этим вы запрещаете аутентификацию сервером клиентов по их сертификатам X.509. Если нужно, чтобы клиент аутентифицировался сервером по введенным клиентом имени и паролю, выберите Yes в полях из строки Name & Password для необходимых вам задач и обеспечьте необходимые документы Person с именами и паролями. Обратите внимание, что клиент при такой «аутентификации» может вводить любое из своих имен – элементов
© InterTrust Co. Тел. 956-7928, 956-7929
144
•
Secure Sockets Layer в Lotus Domino 4.6.1
списка в поле User Name или Short Name, но в списках управления доступом баз необходимо использовать только первый элемент из списка в поле User Name. Если нужно, чтобы клиент мог получать и анонимный доступ к серверным задачам HTTP, LDAP и NNTP, выберите Yes в соответствующем поле в строке Anonymous.
Рис. 10.36 Секция Internet Port and Security Configuration в документе Server Если вы выбрали вариант «Аутентификация клиента и сервера по сертификатам X.509», то в дополнение к предыдущему варианту проделайте следующее.
• • •
•
•
Убедитесь, что клиент имеет сертификат от внешней CA, и эта CA установлена для вашего сервера как Trusted Root. В полях в строке Client certificate выберите Yes для необходимых вам задач. Этим вы разрешаете аутентификацию сервером клиентов по их сертификатам X.509. Для клиента обязательно должен иметься документ Person, причем в поле User Name одним из элементов списка обязательно должно присутствовать общее (Common) имя клиента, в точности так, как оно указано в его сертификате X.509. В то же время в списках управления доступом баз для этого клиента необходимо использовать только первый элемент из списка в поле User Name. Клиент должен «представить свой сертификат» администратору «внутрикорпоративной» CA. Для этого клиент из своего броузера должен открыть базу Certificate Authority (по URL наподобие http://main.inttrust.ru/certca.nsf), выбрать «во фрейме слева» Register Browser Certificate in Address Book, ввести «во фрейме справа» свое имя, адрес электронной почты, телефон и комментарии, и нажать кнопку Submit Certificate. При этом в базе Certificate Authority будет создан документ-запрос. Администратор CA должен «поместить сертификат пользователя в документ Person этого пользователя». Для этого он открывает базу Certificate Authority «локально», выбирает в навигаторе «слева» Client Registration Requests, открывает соответствующий документзапрос и «соглашается» (кнопки Accept и OK) или «отказывается» (кнопка Reject) от помещения сертификата пользователя в его документ Person. Если выбрана опция Send a notification email to the requestor, клиент получит уведомление почтой. Обратите внимание, что изменение в документе Person выполняется «не непосредственно», а с использованием задачи Administration Process. В результате в документе Person пользователя будет создано
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 145
поле UserCertificate, содержащее сертификат X.509 пользователя. Признак наличия этого поля – появление «Present» в поле с меткой X.509 certificate в секции Public Keys.
Рис. 10.37 Сертификат X.509 пользователя помещен в документ Person Когда пользователь устанавливает соединение с сервером, Domino ищет общее (common) имя пользователя, полученное в сертификате X.509, «по полям» User Name документов Person в общей адресной книге. Если соответствие найдено, первый элемент из списка User Name используется при проверке в списках управления доступом баз. Если имя из сертификата X.509 не позволяет однозначно определить документ Person, «уточнение» выполняется по совпадению открытых ключей из сертификата X.509 пользователя и сертификатов X.509 в документах Person. Если в таблице выбраны одновременно только Client certificate и Name & Password, Domino сначала пытается определить документ Person по информации из сертификата X.509. Если сертификат отсутствует в адресной книге, клиент получает запрос на ввод имени и пароля, и затем соответствующий документ Person определяется по имени и паролю. Аналогично, если в таблице выбраны одновременно только Client certificate и Anonymous, Domino сначала пытается определить документ Person по информации из сертификата X.509. Если это не удается, клиент получает «анонимный доступ». Если в таблице выбраны одновременно Client certificate, Name & Password и Anonymous, Domino сначала пытается определить документ Person по информации из сертификата X.509. Если сертификат отсутствует в адресной книге, дальнейшее зависит от того, к какой базе данных обращается клиент. Если список управления доступом базы допускает анонимный доступ, клиент получает «анонимный доступ». Если не допускает, клиент получает запрос на ввод имени и пароля.
Обеспечение SSL-клиентам необходимого уровня доступа к базам на сервере К базам, в окне свойств которых на закладке Basics выбрана опция Force SSL Connection on the Web, доступ через броузер возможен только с использованием SSL. Если сервер поддерживает аутентификацию клиентов с использованием сертификатов X.509, он сразу же предпринимает попытку аутентифицировать обратившегося к нему клиента. Если аутентификация успешна, клиент «получает имя» - первый элемент из списка в поле User Name своего документа Person. Далее такой клиент получает доступ к базе данных подобно обычному пользователю Notes - в соответствии с тем, какой доступ имеет имя клиента в списке управления доступом базы. Поле Maximum Internet name & password access на закладке Advanced в списке управления доступом базы не играет при аутентификации с использованием сертификатов X.509 никакой роли.
© InterTrust Co. Тел. 956-7928, 956-7929
146
Secure Sockets Layer в Lotus Domino 4.6.1
Если сервер поддерживает аутентификацию клиентов «по вводу имени и пароля», но «анонимный доступ» к нему запрещен, сервер сразу же предпринимает попытку аутентифицировать обратившегося к нему клиента, «выдавая ему» окно для ввода имени и пароля. Если аутентификация успешна, клиент «получает имя» - первый элемент из списка в поле User Name. Далее такой клиент получает доступ к базе данных в соответствии с тем, какой доступ имеет имя клиента в списке управления доступом базы, но не выше указанного в поле Maximum Internet name & password access из списка управления доступом базы. Если сервер поддерживает аутентификацию клиентов «по вводу имени и пароля», однако к нему разрешен и «анонимный доступ», сервер по возможности не предпринимает попытки аутентифицировать обратившегося к нему клиента, а «присваивает» ему имя Anonymous. Далее все зависит состояния списка управления доступом той базы данных, к которой обращается клиент. Если имя Anonymous имеет доступ к базе данных (явно как Anonymous, как член группы или -Default-), клиент получает соответствующий доступ к базе данных, но не выше указанного в поле Maximum Internet name & password access. Только когда клиент обращается к базе данных, к которой нет доступа для Anonymous или -Default-, сервер предпринимает попытку аутентифицировать клиента, «выдавая» ему окно для ввода имени и пароля. Если аутентификация успешна, клиент «получает имя» - первый элемент из списка в поле User Name. Далее клиент получает доступ к базе данных в соответствии с тем, какой доступ имеет его имя в списке управления доступом базы, но не выше указанного в поле Maximum Internet name & password access из списка управления доступом базы. Однако при необходимости клиент может «заставить» сервер осуществить его аутентификацию, даже если к базе возможен и анонимный доступ. Для этого в передаваемый серверу URL «после команды» следует добавить аргумент &Login (например, http://main-int.inttrust.ru/mab45.nsf?OpenDatabase&Login).
Как «вынудить» клиентов использовать SSL Чтобы клиенты использовали SSL для доступа из броузеров ко всем базам на сервере Domino, нужно в документе Server в секции Internet Port and Security Configuration выбрать Redirect to SSL в полях из строки TCP/IP port status. Такая возможность не поддерживается только для задач NNTP и POP3. Для того, чтобы «вынудить» клиентов использовать SSL для доступа из броузеров только к некоторым базам на сервере, нужно в окне свойств этих баз на закладке Basics выбрать опцию Force SSL Connection on the Web.
Рис. 10.38 К этой базе доступ через броузер возможен только с использованием SSL и только в случае аутентификации клиента по его сертификату X.509
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 147
10.5. Настройка клиентского броузера Клиент может получить сертификат X.509 для своего броузера как от любой «общеизвестной» Certificate Authority (например, VeriSign, Inc.), так и от Domino Certificate Authority (только для Domino версии не ниже 4.6.1).
Действия при получении сертификата X.509 от «общеизвестной» CA В этом случае клиенту необходимо проделать следующее.
•
• •
Получить сертификат от «общеизвестной» CA. Для этого клиенту обычно придется «посетить» Web-сервер выбранной CA (например, http://www.verisign.com/ для VeriSign, Inc.) и выполнить специфическую для этой CA процедуру. Выпущенный в результате этого «клиентский» сертификат будет помещен в KeyRing-файл броузера. Убедиться, что в броузере имеется самоподписанный сертификат для CA, выпустившей «клиентский» сертификат. При отсутствии получить самоподписанный сертификат этой CA. Установить самоподписанный сертификат CA в качестве Trusted Root. Если сервер Domino тоже сертифицирован «общеизвестной» CA, установить самоподписанный сертификат этой CA в качестве Trusted Root броузера. Если сервер Domino сертифицирован Domino Certificate Authority, получить ее самоподписанный сертификат и установить в качестве Trusted Root. Рис. 10.39 - Рис. 10.43 демонстрируют процесс получения и установки самоподписанного сертификата Domino Certificate Authority в качестве Trusted Root для MS Internet Explorer 4.0. При использовании Netscape Communicator 4.0 этот процесс начинается аналогично, но завершается «проще» - за меньшее количество шагов.
Рис. 10.39 На странице базы Certificate Authority «выбрано» Accept This Authority In Your Browser
© InterTrust Co. Тел. 956-7928, 956-7929
148
Secure Sockets Layer в Lotus Domino 4.6.1
Рис. 10.40 Появляется окно для получения файла с самоподписанным сертификатом, в нем необходимо выбрать Open this file from its current location
Рис. 10.41 Уточнение, в каких случаях должен использоваться этот сертификат
Рис. 10.42 Информация о сертификате
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 149
Рис. 10.43 Проверка – сертификат Domino Certificate Authority «добавлен» в броузер
•
• •
Если требуется аутентификация клиента по его сертификату X.509, зарегистрировать свой сертификат в адресной книге сервера Domino. Для этого необходимо обратиться из броузера к базе Certificate Authority, выбрать Register Browser Certificate in Address Book, заполнить появившуюся форму и нажать в ней кнопку Submit Certificate. Дождаться, пока администратор CA подтвердит регистрацию и сертификат X.509 будет добавлен в документ Person этого пользователя. Проверить работоспособность SSL, обратившись из броузера к какой-либо базе на сервере, доступ к которой возможен только с применением SSL (см. Рис. 10.38), указав URL наподобие https:///.nsf/.
Получение клиентом сертификата X.509 от Domino Certificate Authority В Domino версии не ниже 4.6.1 имеется возможность выпускать сертификаты X.509 для клиентов от имени "самой" Domino CA, причем с одновременной регистрацией их в общей адресной книге. Во-первых, при этом в принципе отпадает необходимость в услугах «общеизвестных» CA все эти услуги предоставляет ваша «внутрикорпоративная» Domino CA. Во-вторых, снимается пусть небольшая, но все-таки забота слежения за тем, чтобы сервер «доверял» самоподписанному сертификату CA, сертифицировавшей клиента, а клиент «доверял» самоподписанному сертификату CA, сертифицировавшей сервер. В-третьих, при этом для обеспечения аутентификации по сертификату клиента последнему нет необходимости предварительно регистрировать свой сертификат в адресной книге сервера - это может происходить автоматически. Рассмотрим последовательность администратором CA.
•
действий,
выполняемых
для
этого
клиентом
и
Клиент из в броузера открывает базу CERTCA.NSF, выбирает левом фрейме Request Client Certificate, заполняет форму в правом фрейме и нажимает кнопку Submit Certificate Request.
© InterTrust Co. Тел. 956-7928, 956-7929
150
Secure Sockets Layer в Lotus Domino 4.6.1
Рис. 10.44 Заполнение формы-запроса на получение сертификата
•
«В ответ» клиент получает подтверждение о приеме запроса на сертификат.
Рис. 10.45 Подтверждение о принятии запроса
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 151
•
Администратор CA обнаруживает запрос клиента «как документ» в виде Client Certificate Requests\Waiting for Approval базы CERTCA.NSF.
Рис. 10.46 Администратор CA «обнаружил» запрос на сертификат
•
Администратор CA открывает этот документ, выбирает в его полях регистрацию сертификата X.509 в адресной книге, уведомление клиента по почте, срок действия сертификата (например, 2 года) и «выпускает» сертификат, нажав кнопку Approve.
Рис. 10.47 «Заголовок» клиентского запроса на регистрацию сертификата X.509
© InterTrust Co. Тел. 956-7928, 956-7929
152
Secure Sockets Layer в Lotus Domino 4.6.1
Рис. 10.48 Администратор CA «подтверждает» выпуск сертификата для клиента
•
Чтобы «подписать» сертификат, необходим секретный ключ CA. Он находится в KeyRingфайле CA на этом сервере. Поэтому администратору CA «для обращения» к KeyRing-файлу приходится ввести соответствующий пароль.
Рис. 10.49 Ввод пароля KeyRing-файла CA
• •
Клиенту автоматически отправляется письмо с уведомлением о выпуске сертификата. Серверная задача Administration Process (ADMINP) автоматически получает «соответствующее задание» и через некоторое время создает для клиента документ Person (если его не существовало ранее) и добавляет в этот документ Person сертификат X.509.
Рис. 10.50 «Следы» работы задачи ADMINP в базе ADMIN4.NSF © InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 153
•
Клиент получает письмо-уведомление о выпуске сертификата. В письме имеется ссылка, по которой этот сертификат можно получить (URL). Клиент "переходит по ссылке"...
Рис. 10.51 Письмо-уведомление о выпуске сертификата
•
Открывается соответствующая страница из базы CERTCA.NSF. Клиент нажимает на этой странице кнопку Accept Certificate, инициирующую процесс передачи сертификата в его броузер.
Рис. 10.52 Кнопка Accept Certificate инициирует процесс передачи сертификата в броузер © InterTrust Co. Тел. 956-7928, 956-7929
154
•
Secure Sockets Layer в Lotus Domino 4.6.1
Клиент получает подтверждение о помещении сертификата KeyRing-файл его броузера.
Рис. 10.53 Броузер принял сертификат
•
Клиент исследует свойства этого сертификата и убеждается, что сертификат действительно выпущен Domino СА.
Рис. 10.54 Свойства сертификата
•
Клиент предпринимает попытку открыть на сервере Domino базу, доступ к которой возможен только с использованием SSL и только при аутентификации клиента по его сертификату X.509 (Рис. 10.38). Попытка завершается успехом.
Рис. 10.55 База, доступ к которой возможен только с использованием SSL и только при аутентификации клиента по его сертификату, открылась
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 155
10.6. SSL, Domino и Notes SSL поддерживается как сервером Domino, так и броузером, входящим в состав клиента Notes (Personal Web Navigator). Реализация SSL в Notes полностью соответствует стандарту SSL 3.0, поддерживаются промышленные стандарты шифрования RSA и CA (Certificate Authorities). За все приходится платить. Если вы применяете SSL, производительность сети несколько снижается (примерно 10-20%). Но снижение производительности сети относительно невелико, а выгоды от использования «защищенного соединения» вполне реальны. Поэтому имеет смысл широко применять SSL для контактов между «не Notes»-клиентом и Domino-сервером. Тем более, что при работе через Internet какой-либо иной способ создания и поддержки соединения, обеспечивающего аутентификацию сторон, шифрование передаваемых данных и контроль того, что передача происходит без искажений, между «не Notes»-клиентом и Domino-сервером в настоящее время попросту отсутствует. Ответы на неизбежные российские вопросы «Законно ли применение SSL?» и «Какова криптоустойчивость алгоритмов шифрования с ключами длиной 40 бит (в связи с экспортными ограничениями правительства США)?» вы сами cможете найти соответственно в Указе Президента Российской Федерации от 3 апреля 1995 года N 334 (например, http://win.www.osp.ru/law/law0013.html) и в статье Павла Семьянова «Почему криптосистемы не надежны?» (http://www.hackzone.ru/articles/ieindex.html). Поддержка SSL сервером Domino ни каким образом не заменяет собственной системы защиты Notes – это лишь предназначенное для специфических нужд (контакт из «не Notes»клиента с сервером Domino и контакт из броузера Notes с «не Domino»-сервером) подмножество из всего множества имеющихся в Notes средств защиты.
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 157
11. Применение eSuite DevPack 1.0 eSuite DevPack - это набор апплетов для размещения в HTML-документах и набор классов, созданных в соответствии со спецификацией JavaBeans, для построения собственных апплетов и приложений. Апплеты eSuite DevPack можно условно разделить на две группы: апплеты доступа к данным и апплеты презентации данных.
Апплеты доступа к данным Апплеты доступа к данным отличаются тем, что обычно не имеют пользовательского интерфейса и применяются разработчиками для получения данных с Web-серверов или JDBCисточников и помещения их в InfoBus, откуда эти данные становятся доступны апплетам презентации данных, или наоборот, для получения данных из InfoBus и помещения их на Webсерверы или в JDBC-источники. В eSuite DevPack 1.0 включены следующие апплеты доступа к данным:
• • • • • •
SQL/JDBC - обмен данными с JDBC-источниками CGI Gateway - обмен данными с CGI-программами TableReader - выборка данных из таблиц в HTML-документе FormReader - выборка данных из форм в HTML-документе FileReader - выборка данных из HTML-документов ScriptHelper - расширяет возможности языков скриптов (JavaScript).
Апплеты презентации данных Апплеты презентации данных предназначены для отображения полученных из InfoBus данных в броузере, а так же для работы с этими данными. В eSuite DevPack 1.0 включены следующие апплеты презентации данных:
• • • • • •
Sheet - электронная таблица Chart - построитель графиков и диаграмм WordProcessor - текстовый редактор Presentation - редактор презентационной графики Scheduler - планировщик проектов AppletContainer - контейнер апплетов.
Приложения eSuite На базе апплетов eSuite DevPack разработчики могут создавать мощные интерактивные кроссплатформные приложения. Основные подходы к их созданию:
• •
включение необходимых апплетов eSuite DevPack в документ HTML (используется HTML и JavaScript); «сборка» собственных апплетов из Bean-компонентов, каковыми являются классы eSuite DevPack (обычно используются визуальные среды разработки Java-приложений).
InfoBus InfoBus - технология обмена данными между апплетами, одновременно выполняемыми одной виртуальной машиной Java. Эта технология была разработана Lotus Development Corporation и в настоящее время включена Sun Microsystems в JDK как стандартное расширение.
© InterTrust Co. Тел. 956-7928, 956-7929
158
Применение eSuite DevPack 1.0
InfoBus c точки зрения разработчика HTML-страниц Необходимые апплеты eSuite DevPack (т.е. соответствующие теги <APPLET>) помещаются в один HTML-документ. Настройка апплетов осуществляется заданием их параметров (теги в тегах <APPLET>) или вызовом методов и свойств апплетов из JavaScript. Поскольку апплеты, содержащиеся в одном HTML-документе, одновременно выполняются в одной виртуальной машиной Java, они имеют возможность обмениваться информацией друг с другом по технологии InfoBus. При этом сам объект InfoBus воспринимается разработчиком как «шина данных», объединяющая данные всех апплетов HTML-документа и позволяющая управлять потоками данных между этими апплетами. Поясним это на «абстрактном» примере Рис. 11.1.
Рис. 11.1 Апплеты eSuite DevPack, «соединенные InfoBus», в одном документе HTML Апплет SQL/JDBC получает данные из JDBC-источника и «публикует» их в InfoBus. Опубликованный в InfoBus элемент данных имеет имя и характеризуется интерфейсом, применяемым для доступа к содержащимся в нем данным. Пусть это будет элемент данных с именем TableData c интерфейсом ArrayAccess. Апплет Sheet «настроен» так, что ожидает появления в InfoBus элемента данных с именем TableData, и, как только он появляется, извлекает содержащиеся в нем данные и отображает их в своем окне «как электронную таблицу». Далее «за дело принимается» пользователь броузера. Предположим, он изменяет данные в электронной таблице. Когда изменения выполнены, данные необходимо отобразить в виде диаграммы в апплете Chart. Чтобы сообщить апплету Chart о факте готовности данных для отображения, пользователь нажимает кнопку в форме. Эта кнопка, «написанная на JavaScript», инициирует публикацию апплетом Sheet элемента данных с именем SheetData и интерфейсом ArrayAccess. Апплет Chart «ожидает» этого события. Как только элемент данных с именем SheetData появляется в InfoBus, апплет Chart извлекает и отображает в виде диаграммы содержащиеся в нем данные. А зачем здесь апплет ScriptHelper? Он не отображается броузером и выполняет вспомогательные функции, расширяя возможности языка JavaScript методами для непосредственной работы с InfoBus и для создания специфических объектов, передаваемых другим апплетам. Приблизительно таковы представления о InfoBus, необходимые для разработчика HTMLстраниц с апплетами eSuite. И, поверьте, ему нет никаких причин изучать устройство InfoBus более подробно, оставаясь в своих рамках.
InfoBus c точки зрения разработчика апплетов, использующего Java Builder Подобным образом воспринимает InfoBus и разработчик прикладных апплетов, когда он «собирает» свой апплет в визуальной среде разработки из готовых Bean-компонентов (классов, © InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 159
которые удовлетворяют спецификации JavaBeans), в том числе из Bean-компонентов, входящих в eSuite DevPack. Пусть в приложении, собранном из Bean-компонентов, «объединенных» InfoBus, один компонент обеспечивает ввод некоторой информации, для простоты, «строки запроса». Когда эта строка введена пользователем приложения, она публикуется в InfoBus. Следующий компонент, допустим, компонент SQL/JDBC, получив «ожидаемую» «строку запроса» из InfoBus, обращается к JDBC-источнику, связанному с внешней базой данных, извлекает откуда соответствующие запросу данные и «через InfoBus» передает их третьему компоненту, допустим, компоненту Chart, который и строит график на основе этих данных. Однако реалии использования eSuite DevPack на таком поприще в настоящее время более скромны.
• •
Хотя классы eSuite DevPack 1.0 и удовлетворяют спецификации JavaBeans, но использование их как Bean-компонентов в визуальных средах разработки не сертифицировано Lotus. Ожидается, что Lotus сертифицирует использование классов eSuite DevPack 1.5 как Beanкомпонентов. По крайней мере классы из версии eSuite DevPack 1.5 Preview (была доступна, когда писались эти строки) были протестированы Lotus в качестве Beanкомпонентов в визуальной среде разработки Symantec Visual Cafe 2.5 for Java.
InfoBus для профессионального разработчика на Java Необходимость в более подробной информации об InfoBus возникает, если нужно создать собственный «InfoBus-совместимый» апплет. Получить InfoBus 1.1 (документация, классы, примеры…) можно с сайта JavaSoft http://java.sun.com/beans/infobus/index.html.
Элементы данных InfoBus, используемые в eSuite DevPack Апплеты eSuite DevPack «работают» с элементами данных следующих интерфейсов.
• • • • • •
ImmediateAccess - содержит одно значение или один объект. ArrayAccess - содержит многомерный массив значений, в eSuite применяются двумерные «массивы». RowsetAccess - содержит набор записей из базы данных, создается апплетом SQL/JDBC. Collection - всевозможные коллекции, реализующие любой из интерфейсов Java Collection, например, Collection, Map, Set и List (см. Java Development Kit, Version 1.2, from Sun Microsystems, Inc.). MinimalMap - eSuite-подмножество интерфейса Map из Java Collection. Например, апплет FormReader публикует элемент данных с интерфейсом MinimalMap, и этот элемент данных может быть использован апплетами Presentation и CGI Gateway. MinimalCollection - eSuite-подмножество интерфейса Java Collection. Объект MinimalCollection может возвращать объект MinimalIterator, который реализует eSuiteподмножество интерфейса Java Collection Iterator для последовательного доступа к элементам объекта MinimalCollection.
Броузеры, в которых работают апплеты eSuite DevPack 1.0 Апплеты eSuite DevPack 1.0 работают только в броузерах Netscape Navigator версии не ниже 4.04 c установленным Netscape patch for Java 1.1.4 или Microsoft Internet Explorer версии не ниже 4.01. Работоспособность всех примеров, приводимых в данной главе, проверялась авторами в Microsoft Internet Explorer 4.01. Только немногие из этих примеров были дополнительно проверены в Netscape Navigator 4.04.
© InterTrust Co. Тел. 956-7928, 956-7929
160
Применение eSuite DevPack 1.0
Размещение апплетов eSuite DevPack Сами апплеты eSuite DevPack могут располагаться на любых стандартных HTTP-серверах, включая Domino, Domino Go WebServer, Microsoft Internet Information Server, Netscape Enterprise Server и др. Обычно все, что относится к eSuite DevPack, помещается на HTTP-сервер в каталог eSuiteDP. Классы для апплетов eSuite DevPack «упакованы» в файлы-архивы двумя методами: JAR и CAB, и расположены соответственно в подкаталогах jars и cabs каталога eSuiteDP. Архивы JAR поддерживаются как броузером Netscape Navigator, так и Microsoft Internet Explorer (но если отсутствуют архивы CAB). Netscape Navigator может «проверять электронную подпись» только для одного файла-архива JAR. Поэтому в случае, если в HTML-документе применяется несколько апплетов eSuite, в броузер должен загружаться один JAR-архив, содержащий классы для всех используемых на странице апплетов eSuite. Microsoft Internet Explorer вообще не «проверяет электронную подпись» для архивов JAR. Архивы CAB поддерживаются броузером Microsoft Internet Explorer, но не поддерживаются Netscape Navigator. Internet Explorer может «проверять электронную подпись» для нескольких файлов-архивов CAB. Поэтому в случае, если в HTML-документе применяется несколько апплетов eSuite, в броузер можно загружать несколько CAB-архивов, каждый из которых содержит классы, относящиеся к одному апплету.
11.1. Апплет ScriptHelper Апплет ScriptHelper (ранее известный как InfoBusBridge), пользовательского интерфейса не имеет. Как и следует из названия апплета, он «добавляется» в HTML-документ исключительно для того, чтобы «в JavaScript этого документа» стали доступны некоторые дополнительные методы. Методы апплета позволяет из JavaScript, содержащегося в HTML-документе, публиковать в InfoBus строки и массивы строк, а так же создавать некоторые специфические Java-объекты (Color, Date, TimeZone, InfoBusVector, DataInputStream, OutputBuffer, DataItemReader), которые необходимы для передачи в качестве аргументов методам и свойствам других апплетов eSuite. Для публикации строк и массивов строк в InfoBus апплет использует объект класса lotus.scripthelper.InfoBusVector, а для получения данных из InfoBus - объект класса lotus.scripthelper.DataItemReader.
Метод createInfoBusVector lotus.scripthelper.InfoBusVector InfoBusVector = ScriptHelper.createInfoBusVector() Создает пустой объект класса InfoBusVector. Для «занесения» данных в объект InfoBusVector используются методы addValue(), appendRow() и appendColumnValue() объекта InfoBusVector. После того, как все необходимые данные занесены в объект InfoBusVector, он передается методу publishVectorToInfoBus() для публикации в InfoBus.
Метод addValue класса InfoBusVector InfoBusVector.addValue(int row, int column, String value) Присваивает новое значение value «элементу массива» InfoBusVector «с индексами» row (номер строки) и col (номер столбца). Нумерация строк и столбцов «начинается с нуля». Если указаны строка или столбец вне текущих границ объекта InfoBusVector, объект автоматически создает необходимое число «пустых» строк или столбцов, чтобы стало возможным добавить этот элемент.
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 161
Метод appendRow класса InfoBusVector int row = InfoBusVector.appendRow() Добавляет новую пустую строку в InfoBusVector и возвращает ее номер.
Метод appendColumnValue класса InfoBusVector InfoBusVector.appendColumnValue(int row, String value) Добавляет новый элемент «вслед за последним имеющимся» в строке row. Если происходит «выход за текущие границы» InfoBusVector, его границы автоматически расширяются.
Метод publishVectorToInfoBus ScriptHelper.publishVectorToInfoBus(String itemName, InfoBusVector InfoBusVector) Публикует объект InfoBusVector, содержащий двумерный массив строк, в InfoBus «под именем» itemName как элемент данных с интерфейсом ArrayAccess. Если для элемента данных было указано «новое» имя (ранее не существовавшее в InfoBus), соответствующий элемент данных будет добавлен в InfoBus. Если же было указано имя, совпадающее с именем уже имеющегося в InfoBus элемента данных, прежний элемент будет удален и заменен новым, имеющим то же имя.
Метод publishStringToInfoBus ScriptHelper.publishStringToInfoBus(String itemName, String itemValue) Публикует в InfoBus «одну строку» itemValue под именем itemName как элемент данных с интерфейсом ImmediateAccess. Если указано «новое» (ранее не существовавшее в InfoBus) имя элемента данных, элемент будет добавлен в InfoBus. Если указано имя элемента данных, который уже был ранее опубликован методом publishStringToInfoBus() этого же экземпляра апплета ScriptHelper, новое значение заменяет старое в существующем в InfoBus элементе данных. Если указано имя элемента данных, которое было ранее опубликовано методом publishVectorToInfoBus(), старый элемент данных удаляется и затем публикуется новый.
Метод readStringFromInfoBus String datastring = ScriptHelper.readStringFromInfoBus(String itemName) Выбирает данные из элемента данных InfoBus с именем itemName и возвращает их как строку, если элемент данных с указанным именем существует в InfoBus и поддерживает интерфейс для получения значения в форме строки (presentation string) или имеет строковое значение (value string). В противном случае возвращается null. Для элементов данных с интерфейсом ImmediateAccess возвращается presentation string, форматируемая в соответствии с текущей местностью пользователя (current locale).
Метод findInfoBusItem lotus.scripthelper.DataItemReader DataItemReader = ScriptHelper.findInfoBusItem(String itemName) Возвращает новый объект класса DataItemReader, позволяющий получить доступ к данным из содержащегося в InfoBus элемента данных с именем itemName, или null, если этот элемент данных не доступен. Методы класса DataItemReader позволяют определить, какой интерфейс поддерживает элемент данных, а так же извлечь данные из элемента данных с интерфейсом ArrayAccess или ImmediateAccess.
© InterTrust Co. Тел. 956-7928, 956-7929
162
Применение eSuite DevPack 1.0
Метод isImmediateAccess класса DataItemReader boolean flag = DataItemReader.isImmediateAccess() Если элемент данных поддерживает интерфейс ImmediateAccess, возвращает true, иначе false.
Метод readImmediateValueAsString класса DataItemReader String value = DataItemReader.readImmediateValueAsString() Если элемент данных поддерживает интерфейс ImmediateAccess, возвращается его значение как строка. Возвращаемая строка вычисляется как presentation string, если элемент данных поддерживает эту функцию, иначе как value string. Если же элемент данных не поддерживает интерфейс ImmediateAccess, или поддерживает, но значение не может быть получено, возвращается null.
Метод readImmediateValueAsObject класса DataItemReader Object objRef = DataItemReader.readImmediateValueAsObject() Если элемент данных поддерживает интерфейс ImmediateAccess, возвращается ссылка на объект, представляющий его значение. В противном случае возвращается null.
Метод isArrayAccess класса DataItemReader boolean flag = DataItemReader.isArrayAccess() Если элемент данных поддерживает интерфейс ArrayAccess, возвращает true, иначе false.
Метод getDimensionCount класса DataItemReader int dimCount = DataItemReader.getDimensionCount() Возвращает количество измерений элемента данных ArrayAccess или 0, если элемент данных не поддерживает интерфейс ArrayAccess.
Метод getDimensionSize класса DataItemReader int indexCount = DataItemReader.getDimensionSize(int dimension) Возвращает размерность (количество элементов) элемента данных ArrayAccess по измерению dimension. Измерения «номеруются с нуля» - двумерный массив имеет измерения с номерами 0 и 1. Если элемент данных не поддерживает интерфейс ArrayAccess или поддерживает, но указано несуществующее измерение, возвращается -1.
Метод readArrayValueAsString класса DataItemReader String value = DataItemReader.readArrayValueAsString(String coords) Для содержащегося в «массиве ArrayAccess» элемента, определенного «строкой индексов» coords, возвращает строку, содержащую значение этого элемента. Например, «строка индексов» "1,0,8" определяет «элемент трехмерного массива» с индексом [1][0][8]. Если элемент InfoBus не поддерживает интерфейс ArrayAccess, возвращается null. Если поддерживает, но «строка индексов» указывает на несуществующий «элемент массива», возвращается пустая строка ("").
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 163
Метод dispose класса DataItemReader DataItemReader.dispose() Освобождает ссылку на объект DataItemReader. Должен вызываться после того, как объект DataItemReader «стал более не нужен». Пример 1. В приведенном ниже фрагменте HTML-документа демонстрируются основные приемы «ручного» занесения информации в InfoBus и «ручного» получения информации из InfoBus. Кнопка Fields as myOutput (см. Рис. 11.2) создает объект InfoBusVector, заносит в него информацию из полей формы и затем публикует ее как элемент данных ArrayAccess с именем myOutput. Кнопка MyString as myOutput1 публикует строку «MyString» как элемент данных ImmediateAccess с именем myOutput1. Кнопки Read myOutput1 и Read myOutput «исследуют свойства и получают значения» опубликованных в InfoBus элементов данных.
Рис. 11.2 Внешний вид HTML-документа в броузере
Кнопка публикует в InfoBus вектор данных из расположенных выше полей
Кнопка публикует в InfoBus строку "MyString"
Кнопка читает из InfoBus строку MyString
Кнопка получает из InfoBus информацию о векторе
© InterTrust Co. Тел. 956-7928, 956-7929
166
Применение eSuite DevPack 1.0
Метод createColor java.awt.Color Color = ScriptHelper.createColor(String colorSpecifier) Преобразует заданное строкой название или 16-ричное RGB-значение цвета в объект класса java.awt.Color.
Метод createDate java.util.Date Date = ScriptHelper.createDate(String datestring) Преобразует строку, содержащую «дата-временное» значение, в объект класса java.util.Date. Строка анализируется согласно соглашению о локализации (настройка приложения на работу в определенной местности и на определенном языке) в части формата записи даты и времени в соответствии с текущей местностью пользователя (user's current locale). Информация о времени игнорируется. Вначале предпринимается попытка «разобрать» строку с использованием стиля FULL (см. класс java.text.DateFormat), при неуспехе - стиля LONG, затем MEDIUM и, наконец, SHORT. Если все попытки завершились неуспешно, возвращается null.
Метод createTimeZone java.util.TimeZone TimeZone = ScriptHelper.createTimeZone(String zoneName) Создает объект класса java.util.TimeZone, соответствующий временной зоне, название которой задано строкой zoneName (например, "EST"). Если указанная строка не может быть «понята» пользовательской виртуальной машиной Java, возвращается null.
Метод createOutputBuffer lotus.scripthelper.OutputBuffer OutputBuffer = ScriptHelper.createOutputBuffer() Создает «пустой» объект класса lotus.scripthelper.OutputBuffer. Во-первых, объект OutputBuffer содержит метод, позволяющий разработчику создать поток вывода данных java.io.DataOutput для записи в объект OutputBuffer любой информации в форме строк. Во-вторых, ряд апплетов eSuite содержат методы для «выгрузки» содержащихся в них документов в поток вывода данных. Наконец, объект OutputBuffer содержит метод, позволяющий извлечь всю информацию, уже записанную в объект OutputBuffer через поток вывода данных, как одну строку символов, с применением по желанию нужного кодирования символов.
Метод getOutputStream класса OutputBuffer java.io.DataOutput DataOutput = OutputBuffer.getOutputStream() Возвращает поток вывода данных (объект класса java.io.DataOutput), связанный с объектом OutputBuffer.
Метод saveDocumentToStream ряда апплетов eSuite boolean isSaved = myApplet.saveDocumentToStream(java.io.DataOutput outputStream) Сохраняет документ, содержащийся в апплете, в указанном потоке вывода данных (объекте класса java.io.DataOutput), используя при этом «формат по умолчанию» для соответствующего документа. Метод применим к апплетам AppletContainer, Chart, Presentation, Scheduler, Sheet и WordProcessor. Если сохранение завершилось успешно, возвращается true, иначе false.
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 167
Метод getString класса OutputBuffer String contents = OutputBuffer.getString(String encoding) Возвращает все данные, содержащиеся в объекте OutputBuffer, в форме строки. Аргумент encoding позволяет задать кодировку символов для возвращаемой строки. По умолчанию применяется кодировка "PSUU16" (pseudo-uuencoding, 16 values or 4 bits per character). Любые нераспознанные кодировки интерпретируются как «отсутствие перекодировки».
Метод createInputStream java.io.DataInput DataInput = ScriptHelper.createInputStream(String contents, String encoding) Создает поток ввода данных (объект класса java.io.DataInput) для доступа к содержимому строки contents. Аргумент encoding позволяет указать кодировку символов в строке contents. По умолчанию предполагается кодировка "PSUU16". Любые нераспознанные кодировки интерпретируются как «отсутствие перекодировки». Содержимое строки contents впоследствии будет извлекаться из объекта java.io.DataInput как unencoded или plain text. Кроме того, ряд апплетов eSuite содержат методы для «загрузки» в них документов из потока ввода данных.
Метод openDocumentFromStream ряда апплетов eSuite boolean isOpened = myApplet.openDocumentFromStream(java.io.DataInput inputStream, boolean promptToSave) Открывает в апплете новый документ и заносит в него данные из потока ввода данных (объекта класса java.io.DataInput). Применим к апплетам AppletContainer, Chart, Presentation, Scheduler, Sheet и WordProcessor. Апплет, который «загружает» данные из потока, интерпретирует их в своем «формате по умолчанию». Если аргумент promptToSave равен true, и пользователь сделал изменения в «текущем» документе апплета, то при закрытии «текущего» документа будет появляться диалоговое окно с запросом о его сохранении или отмене внесенных изменений. Если же аргумент promptToSave равен false, такое диалоговое окно не появляется и «текущий» документ не сохраняется. Метод возвращает true, если «загружаемый» документ был успешно открыт, или false, если если документ не удалось загрузить или если пользователь выбрал Cancel в диалоговом окне при сохранении «текущего» документа. Applet1
Документ
java.io.DataOutput
OutputBuffer
Applet2 Документ
java.io.DataInput
Java String
Рис. 11.3 Логика передачи документа из одного апплета в другой Таким образом, использование объекта OutputBuffer дает возможность из JavaScript преобразовать выходной поток апплета в строку символов, по желанию с применением
© InterTrust Co. Тел. 956-7928, 956-7929
168
Применение eSuite DevPack 1.0
нужного кодирования, а затем передавать эту строку другому апплету или «на сервер», CGIпрограмме «по заданному URL». Пример 2. Приведенный ниже фрагмент на JavaScript демонстрирует передачу документа из одного апплета eSuite в другой (см. Рис. 11.3). Документ, загруженный в апплет Applet1, выгружается в поток вывода данных, связанный с объектом OutputBuffer. Затем содержимое объекта OutputBuffer (документ) без перекодировки преобразуется в строку. Далее создается поток ввода данных, содержащий информацию из этой строки. Наконец, информация из потока ввода данных загружается в апплет Applet2. Подобный же прием будет продемонстрирован позже, при рассмотрении апплета Sheet, для передачи «документа-таблицы» на Web-сервер и последующей загрузки с Web-сервера в апплет. // Создаем объект OutputBuffer, // scrhlp - имя экземпляра апплета ScriptHelper ob = scrhlp.createOutputBuffer(); // В связанный с объектом OutputBuffer поток вывода данных // записываем документ из апплета applet1 applet1.saveDocumentToStream(ob.getOutputStream()); // Теперь этот документ без перекодировки извлекаем в строку docString = ob.getString(""); // Создаем поток ввода данных, содержащий эту строку (без перекодировки) // и загружаем "информацию из строки" в апплет applet2 applet2.openDocumentFromStream(scrhlp.createInputStream(docString, ""));
11.2. Апплет FileReader Публикует в InfoBus данные из восьми-битного ASCII последовательного файла как двухмерный элемент данных с интерфейсом ArrayAccess. Байт-код апплета - Filereader.class. Для работы апплета в броузер должен быть загружен JAR-архив devpack_filereader_app.jar или CAB-архив devpack_filereader_app.cab. Апплет разбирает входной файл на лексемы (токены), используя в пределах строки пробелы в качестве символа-разделителя. При этом апплетом используется класс java.io.StreamTokenizer. Каждая лексема из строки входного файла заносится в отдельный элемент в строке выходного массива, а каждая строка входного файла - в отдельную строку выходного массива.
Параметр и свойство OutputItemName FileReader.setOutputItemName(String name) String name = FileReader.getOutputItemName() Имя публикуемого в InfoBus элемента данных, который будет содержать информацию из входного файла апплета. По умолчанию используется имя экземпляра апплета (из атрибута NAME в теге <APPLET>), а если его нет, то "FileReaderOutput".
Параметр и свойство DocumentName FileReader.setDocumentName(String fileName) String fileName = FileReader.getDocumentName() URL входного файла для апплета. Для доступа к локальным файлам используется конструкция "file:///c:\/filename.extension", например,
© InterTrust Co. Тел. 956-7928, 956-7929
Разработка Web-приложений на основе Lotus Domino 4.6.x и Lotus eSuite DevPack 1.0 169
Параметр и свойство DocumentNameItemName FileReader.setDocumentNameItemName(String dinFileIn) String dinFileIn = FileReader.getDocumentNameItemName() Игнорируется, если был задан параметр documentName. Сообщает имя элемента данных с интерфейсом ImmediateAccess, который должен содержать URL для получения входного файла апплета. Апплет ожидает этот элемент данных, а по его появлении выполняет разбор указанного в нем файла и публикацию в InfoBus содержащихся в файле данных. При использовании параметра одним экземпляром апплета можно последовательно «загрузить в InfoBus несколько файлов». При каждом изменении имени файла в элементе данных dinFileIn соответствующий файл «разбирается и публикуется, заменяя в InfoBus старый».
Параметр debug Значение true разрешает протоколирование в System.out основных событий при работе апплета, а значение false (по умолчанию) - запрещает протоколирование. Если выбрано true, апплет также выполняет протоколирование основных событий при работе InfoBus.
Параметр verbose Значение true разрешает протоколирование в System.out публикуемых в InfoBus данных (содержимого массива, полученного из файла), а значение false (по умолчанию) - запрещает. Если выбрано true, апплет также выполняет протоколирование основных событий при работе InfoBus. Пример 1. Приведенный фрагмент HTML-кода «минимально-необходим» для запуска апплета FileReader. HTML-документ, содержащий апплет, имеет URL http://main.inttrust.ru/eSuite.nsf/byKeys/0102-001?OpenDocument. Апплет при своей инициализации читает входной файл "../Images/FileReader/$File/FileReader.txt?OpenElement" (присоединенный файл FileReader.txt из документа «с ключем» FileReader в виде Images этой же базы) и публикует его содержимое в InfoBus под именем «dinFileOut». <APPLET CODEBASE="/eSuiteDP" CODE="lotus.scripthelper.ScriptHelper" ARCHIVE="jars/devpack_chart_app.jar" NAME="ibBridge" WIDTH=1 HEIGHT=1> <SCRIPT LANGUAGE="JavaScript">
Введите URL публикуемого файла и нажмите OK.
11.3. Апплет TableReader Апплет получает HTML-код (обычно по заданному URL), находит в нем нужную таблицу (тег