Освоение и использование полей Reader Names в IBM Lotus Notes и Domino

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

Уровень сложности: средний

Рафаэль Сейвир, главный разработчик, LS Development Corporation

03.05.2007

Воспользуйтесь преимуществами и реализуйте чрезвычайно полезную функцию IBM Lotus Notes и Domino, связанную с системой защиты поля Reader Names. Узнайте, как эта функциональность влияет на репликацию, агентов и виды, а также как решать обычные проблемы при работе с полями Reader Names.

Поля Reader Names (известные также под названием Reader and Author Access или Reader Names) ограничивают доступ к документам в базах данных IBM Lotus Notes и Domino. Эта функция обеспечивает надежную защиту от нежелательного вмешательства и предоставляет простой доступ указанным пользователям к документам, которые они должны видеть. Другими словами, это интеллектуальный и контролируемый способ предоставления прав доступа. В данной статье рассматривается план реализации полей Reader Names и дается несколько советов, помогающих избежать проблем при их реализации.

Данная статья предназначена для разработчиков приложений Notes/Domino, хотя для понимания концепций и примеров особого опыта не требуется.

Обзор методов защиты в Lotus Notes/Domino

Lotus Notes/Domino предоставляет много методов защиты базы данных. Приведем краткий обзор часто применяемых методов, для того чтобы показать, как в них вписываются поля Reader Names:

1. Физический доступ. Если ваш сервер находится в помещении без кабелей, подключения к сети и без доступа через модем, то естественно, данные имеют определенный уровень защиты просто благодаря физической недоступности кого-либо к помещению. Хотя теоретически это прекрасный вариант, обычно такой метод защиты не является хорошим решением для большинства данных.
2. Серверный доступ. Сервер Lotus Domino разрешает/запрещает доступ пользователей на основе списков доступа в документе Server. Эта функция наиболее часто применяется для запрета доступа уволенным работникам, которые все еще могут иметь корректный ID и подключаться к сети.
3. Access Control List (ACL). Каждая база данных имеет свой собственный ACL, который может разрешать/запрещать доступ пользователям на основе их индивидуального имени, групп, которым они принадлежат, или иерархии их ID.
4. Поля Reader Names. Эта функциональность может разрешать/запрещать доступ к отдельным документам на основе таких же критериев, которые используется в ACL. Кроме того, можно использовать [roles] (роли), определенные в ACL.
5. Шифрование. Эта функциональность позволяет разрешать/запрещать доступ к отдельным полям отдельного документа. Шифрование можно использовать на основе имени пользователя или секретного ключа, который совместно используется ID-файлами на физическом уровне.

Хотя каждая из этих тем является интересной и стоит рассмотрения, в данной статье внимание уделяется защите данных с использованием полей Reader Names.

Если пользователь, использующий Notes-клиент или Web-браузер, имеет доступ к базе данных, мы можем предположить, что ему был предоставлен доступ по первым трем пунктам приведенного выше списка. Если не принять дальнейших мер защиты (например, использовать поля Reader Names), этот пользователь теоретически может найти способ доступа к любому документу. Например, скрытие данных путем не включения их в главные виды (что легко выполнить с точки зрения разработки) не защищают данные от того, кто настойчиво ищет их.

На основе нескольких лет изучения, тестирования и использования различных механизмов защиты, доступных в Lotus Notes/Domino, мы создали таблицу 1, помогающую решить, какие из них наиболее подходят для различных приложений.

ПРИМЕЧАНИЕ: Скрытие данных путем не отображения в общедоступных видах или скрытие данных формы с использованием формул hide-when называется термином "запутывание" (obfuscation). Это не настоящая защита, но она может быть полезна в определенных контекстах.

Из таблицы 1 видно, что использование полей Reader Names имеет некоторые мощные преимущества по сравнению с другими формами защиты. Они обеспечивают реальную защиту, но также удобны для использования при наличии соответствующих прав доступа как из Notes-клиента, так и из Web-браузера. Немаловажно также то, что данные можно просматривать в видах, а агенты могут обращаться к данным программным способом. Наконец, их относительно легко реализовать и изменить при возможных будущих изменениях требований к защите или бизнесу.

В начало

Реализация полей Reader Names

Для использования полей Reader Names обычно устанавливается тип поля в Readers в диалоговом окне Field Properties (см. рисунок 1). После заполнения этих полей именем пользователя, именами групп или ролей (рассматривается далее в этой статье) только указанные пользователи могут видеть документы, основанные на этой форме.

Полезно сделать это поле многозначным, так чтобы вы могли добавить более одного имени. При сохранении документа с этой формой и просмотре его свойств можно увидеть, что Field Flags установлены в SUMMARY READ-ACCESS NAMES (см. рисунок 1). Это означает, что данные можно просмотреть в видах (SUMMARY) и что это поле Reader Names (READ-ACCESS NAMES). Частой ошибкой при использовании полей Reader Names является пропуск установки корректного типа поля, поэтому выполнение такой быстрой проверки свойств документа является хорошим способом убедиться в том, что все установлено правильно (см. рисунок 2).

Использование множественных полей Reader Names

В форме можно иметь несколько полей Reader Names. При этом для определения того, кто имеет доступ, берутся совокупные имена из всех полей Reader Names. Кроме того, каждый, имеющий способность редактировать документ, может добавлять список Reader (последняя закладка свойств документа), который сохраняется как поле, называемое $Readers. Если такое поле добавлено, оно обрабатывается также как и все другие поля Reader Names в смысле определения прав доступа к документу.

Использование полей Author

Если вы создаете поле Author, то оно должно иметь свойство SUMMARY READ-WRITE ACCESS. Интересно, что если бы в документе имелось только поле Author, и не было бы поля Reader Names, каждый мог бы увидеть его. Но только пользователи с правами доступа Author к базе данных, перечисленные в поле Author, могут редактировать его, а также каждый, кто имеет права Editor или выше в ACL, независимо от присутствия его/ее имени в поле Author.

Однако, если имеется также поле Reader Names, поле Author служит как списком Reader, так и как списком Editor. Предположим, что имеется некто с правами доступа Editor в ACL, но его имя не указано ни в одном из полей. Этот пользователь не может видеть документ и, следовательно, не может редактировать его, даже если имеет права Editor для всех документов в базе данных. Если имя пользователя находится в поле Reader либо в поле Author документа (может иметься любое количество каждого типа), то этот пользователь может читать и редактировать документ.

Можно добавить также такое поле в документ программно, используя LotusScript. В этом случае код может выглядеть следующим образом (листинг 1):

                
Dim item as NotesItem
Set item = doc.ReplaceItemValue ( "RNames", NewValue )
Item.IsReaders = True
‘ Item.IsSummary = True

В этом коде RNames - это имя вашего поля Reader Names, а NewValue - это строка или массив строк. Также, Item.IsSummary = True является излишней в последних версиях Lotus Notes/Domino; в старых версиях было необходимо гарантировать, что новое поле сохраняется как итоговые данные.

Если вы попытаетесь добавить новое поле Reader Names в документ, используя язык @Formula, соответствующий тип не присвоится. Поле будет считаться текстовым. При проверке свойств документа вы увидите SUMMARY, а не SUMMARY READ ACCESS. Однако, если поле уже существует и вы обновляете содержимое, язык @Formula сохраняет корректные атрибуты Reader.

Форматирование имен

Поля Reader Names и Author должны иметь индивидуальные имена в неструктурированном либо в каноническом, но не в сокращенном, формате. Подходят, например, варианты CN=Raphael Savir/OU=Boston/O=LSDevelopment или Raphael Savir, но Raphael Savir/Boston/LSDevelopment не работает.

Это может привести в некоторое замешательство, поскольку поля Reader Names или Author отображают канонические данные в сокращенном формате для облегчения чтения. При открытии документа и чтении имен в таком поле вы увидите Raphael Savir/Boston/LSDevelopment. Но если посмотреть на эти данные, используя свойства документа, вы увидите, что на самом деле они хранятся канонически: CN=Raphael Savir/OU=Boston/O=LSDevelopment (см. рисунок 3). Данная способность очищать канонические имена действует на все поля Names, но это не так для обычных текстовых полей.

Если поместить имя в обычном формате в поле Reader Names или Author, оно будет работать только в том случае, если сервер имеет такую же иерархию, что и пользователь. Например, предположим, что ваша компания сливается с другой компанией, и у вас есть данные, реплицируемые между серверами разных иерархий. Назовем одну Apps/NorthEast/LSDevelopment, а вторую HQ/ACME. Если пользователь пытается обратиться к данным в каждой копии, и если его данные хранятся в полях Reader Names в формате обычных текстовых (flat) имен, он сможет получить данные только на сервере Apps/NorthEast/LSDevelopment, поскольку имеет общую иерархию только с этим сервером (часть /O= его имени). Он может быть сертифицирован для доступа на другой сервер, HQ/ACME, но поля Reader Names и Author не предоставят ему доступ к самим данным.

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

В начало

Использование ролей

ПРИМЕЧАНИЕ: В данной статье при рассмотрении бизнес-ролей мы употребляем слово "роль" как обычно. Однако при обращении к функциональности, имеющейся в ACL каждой базы данных Notes, мы заключаем слово в квадратные скобки: [роли].

При первом использовании поля Reader Names возникает желание поместить в это поле имена всех пользователей, которым требуется доступ к данному документу. Однако это не практично, поскольку если бизнес-роль пользователя в компании меняется, то может понадобиться изменение его имени во многих документах, иногда в сотне или тысяче. Хотя это возможно сделать аккуратно, совсем не хочется оказаться в подобной ситуации, пока не остается ничего другого. Во многих компаниях такое случается часто, поэтому необходимо подготовиться к этому.

Кроме того, поля Reader Names могут ссылаться на большую группу людей. Например, все 30 директоров и руководителей вашей компании должны видеть в приложении все данные о продажах. Повторять все эти имена для каждого документа – только тратить место, а кроме того, чем больше имен, тем чаще нужно будет делать изменения в этом списке имен. Наконец, хотя и редко, но список имен может превысить предел (32K SUMMARY) данных для поля.

Вместо этого везде, где возможно, рекомендуется использовать группы или [роли]. Теоретически подходит любой вариант, но на практике вы должны использовать по возможности [роли]. Одним из различий между группами и [ролями] является то, что группы обслуживаются в Domino Directory. Существует несколько тысяч групп, их названия могут меняться, например, если компания объединилась с другой компанией, и всегда есть вероятность повреждения каталога или возникновения других проблем, которые невозможно решить персонально. На рисунке 4 показан ACL с ролью, назначенной пользователю Rafael Savir/Boston/LSDevelopment.

С другой стороны, [роли] являются индивидуальными для вашего приложения. Несколькими щелчками в ACL можно назначить [роль] одной группе или нескольким. Можно взять [роль] из одной группы и назначить ее другой, или, при крайней необходимости, можно назначить [роль] конкретным именам в ACL. Встречались критические ситуации, когда повреждался каталог, но пользователям предоставлялся полный доступ к важным данным путем временного добавления их имен в ACL и назначения соответствующих [ролей] их именам. Если бы поля Reader Names использовали группы вместо [ролей], это было бы невозможно.

Чтобы использовать [роли] таким способом, подумайте о группе или группах, нуждающихся в доступе к защищенным документам. Предположим, что имеются следующие группы:

• Executive Committee
• HR Reps
• Sales Management Team

Подойти к задаче предоставления этим людям доступа можно двумя путями. Один - создать [роль] для каждой группы, а второй - создать одну [роль] и назначить ее всем трем группам. Все зависит от конкретной ситуации, но поскольку можно иметь до 75 [ролей], обычно можно свободно создавать и назначать их. За многие годы использования [ролей] при разработке приложений мы выработали несколько руководящих принципов, приведенных ниже, которые хорошо работали в нашем случае. Это не абсолютные правила, но в каждом случае их применение предотвращало различные проблемы:

1. Хранить их названия короткими. Это экономит дисковое пространство и делает более вероятным правильное написание [роли] в коде, что, несомненно, станет необходимым со временем.
2. Не использовать пробелы или другие странные знаки пунктуации. Опять же, это облегчает корректное их написание, кроме того, вы избегаете проблем при полнотекстовом поиске и, потенциально, в Web-приложениях при необходимости передачи [роли] в URL.
3. Неплохо было бы имитировать имя группы, но помните, что имя группы со временем может измениться.
4. Всегда сохранять как минимум одну [роль] для ваших разработчиков и/или администраторов. Иными словами, если есть группа с названием Development, не создавайте [роль], называемую просто [Dev] или [Development], поскольку это, вероятно, [роль], которую вы должны использовать для реальных Notes/Domino-разработчиков, работающих над этим приложением. Для другой группы примените, например, название [ProdDev].

Итак, в нашем примере мы создали поля Reader Names со следующими [ролями]:

• [Execs]
• [HR]
• [SalesManagers]
• [Dev]
• [Admin]

Обратите внимание на последние две, добавленные для возможности предоставления доступа к данным всем разработчикам и администраторам.

В начало

Влияние полей Reader Names на репликацию, агентов и виды

Теперь, когда точно известно, как настроить ваши [роли] и поля Reader Names, нужно потратить несколько минут на обдумывание других способов доступа к данным. Конкретнее, мы обнаружили, что репликация, агенты и виды могут иногда проявлять неожиданное поведение после применения полей Reader Names в документах. В данном разделе мы подробнее рассмотрим каждый из них.

Репликация

Если выполняется репликация на серверах, единственное, о чем необходимо подумать, - включение всех серверов в роль [Admin], как рассматривалось ранее. Это можно сделать через группу LocalDomainServers, гарантируя возможность просмотра всех ограниченных с использованием полей Reader документов в базе данных всеми серверами домена.

Если вы не хотите делать репликацию на все сервера, нужно несколько изменить этот подход. Одним из примеров может быть большое приложение по продажам, в котором каждый географический регион обслуживает только свои собственные данные для обеспечения должной производительности. В этом случае можно было бы использовать, например, такие [роли] как [Servers-APAC], [Servers-EMEA] и т.д. и назначить эти [роли] документам согласно их географическому региону, а затем конкретным именам серверов в вашем ACL. Все еще необходимо быть внимательным, чтобы непреднамеренно не предоставить всем серверам доступ ко всем данным через LocalDomainServers или какую-либо другую группу. Внимательно тестируйте приложение после применения такого рода модели.

Более неприятная проблема возникает при работе с локальной репликацией. Например, предположим, что каждый из ваших 20000 торговых представителей имеет лэптоп и выполняют репликацию своих собственных данных локально каждую ночь. Без полей Reader Names, возможно, возникнет необходимость побеспокоиться о конфликтах репликации/сохранения, но это все. С полями Reader Names существует также вероятность того, что локальные копии станут не синхронизированными с копией на сервере, если документ редактируется и на локальной и на серверной копии, а на сервере имя этого пользователя было удалено из полей Reader Names.

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

Агенты

Что касается системы защиты через поля Reader, агенты на самом деле работают очень понятно. Если агент активизируется пользователем, например, по нажатию кнопки, то агент работает так, как выполнял бы эти действия этот пользователь. Если этот пользователь имеет доступ к документу, агент тоже может обратиться к документу. Если пользователь не имеет доступа к рассматриваемому документу, отображается информация об ошибке при работе агента (например, "Entry not found in index" (Элемент в индексе не найден) или "Unauthorized to attempt that operation" (Нет полномочий для выполнения данного действия)).

Если агентом является запланированный агент, он выполняется, как если бы был пользователем-подписчиком этого агента. Если поле "Run on behalf of" агента заполнено, он работает, как если бы был указанным пользователем (см. рисунок 5).

Виды

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

Если вид категоризирован, пользователи могут увидеть категорию, но могут не увидеть документы в этой категории. Пользователи очень часто жалуются на это. Одним из решений является создание встроенного вида, используя параметр Show single category (см. рисунок 6), чтобы пользователь выбирал категорию для отображения из списка категорий, к которым имеет доступ. При этом пользователь не увидит другие категории и не обнаружит пустых видов. Эта функциональность работает нормально в Web-браузерах и может использоваться также для Notes-клиентов. Другим решением является пересмотр ваших категорий таким образом, чтобы пользователи не находили пустых категорий.

Поля Reader Names могут сделать работу с видом намного более медленной, чем было бы в противном случае, поскольку сервер должен проверять каждый документ, для того чтобы убедиться в возможности его просмотра. Это должно делаться для каждого пользователя, поэтому, если у вас имеется много одновременно работающих пользователей и много документов с полями Reader Names, работа вашего сервера/приложения может замедлиться очень значительно. Это особенно верно, когда много пользователей имеют доступ к небольшому набору документов в виде, как, например, в приложениях поддержки продаж или HR-приложениях. Опять же, наилучшим решением является создание встроенного вида с использованием параметра Show single category, что обычно быстрее, чем открытие оригинального вида вовсе без ограничений Reader в документах.

В качестве альтернативы можно категоризировать и изначально свернуть вид. Это повысит скорость, хотя может привести к рассмотренным ранее проблемам: пользователи видят категорию, но не могут увидеть каких-либо документов в этой категории. В некоторых случаях имеет смысл разбить данные на несколько видов, а затем направить пользователя на нужный вид. Например, если пользователь нажимает мышкой на Regional Sales в панели навигации, можно применить формулу, проверяющую @UserRoles, а затем открыть соответствующий вид (Sales-US, Sales-APAC и т.д.).

Дополнительная информация по производительности видов приведена в статье по Lotus на developerWorks "Производительность приложений Lotus Notes/Domino 7: Часть 2: Оптимизация видов баз данных".

В начало

Устранение проблем

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

Многозначные поля Reader Names

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

Например, предположим, что вы добавили роль [HR] в поле Reader Names. Через год вы решили, что имеет смысл поместить в него также роль [ProdDev]. Вы пишете агент, добавляющий это значение, тестируете для пользователя, имеющего роль [ProdDev], но не имеющего роли [HR], и все выглядит отлично. Но если вы забудете изменить свойства поля в форме, в следующий раз, когда кто-то сохранит документ с этой формой, ваше значение Reader будет выглядеть как "[HR], [ProdDev]" вместо "[HR]" "[ProdDev]". Другими словами, поле Reader Names теперь ищет пользователя или группу с именем [HR], [ProdDev] (где запятая просто является частью имени, а не разделителем значений), и никто не будет иметь доступа к документу.

Простой способ избежать этой проблемы - всегда делать поля Reader Names/Author многозначными.

Восстановление скрытых документов

Если вы используете в документах поля Reader Names и нечаянно сделали некоторые документы недоступными для всех пользователей (например, вставив многозначные записи в однозначное поле, как описано выше), можно использовать режим Full Access Administration (см. рисунок 7) для открытия базы данных и восстановления этих документов. Предварительно создайте агент, применяющий соответствующие значения Reader, а затем, в режиме Full Access Administration можете активизировать этот агент для исправления данных.

В большинстве организаций только избранная группа администраторов может использовать режим Full Access Administration, поэтому пользователи должны встать в очередь на выполнение этой задачи, но, во всяком случае, это можно сделать без физического доступа к серверу, используя локальный Notes-клиент для обхода системы защиты Reader.

В начало

Заключение

Мы надеемся, что данная статья поможет как можно более безболезненно и эффективно спланировать и реализовать поля Reader Names. Это прекрасная функциональная возможность и отличная мера защиты. Ее легко реализовать и поддерживать, если настроить все заранее. Главное здесь помнить только одно: настроить все заранее. Если вы сделаете так, то все будет работать отлично, и вы увидите преимущества этой прекрасной функциональной возможности Lotus Notes/Domino.

Ресурсы

• Оригинал статьи "Using and understanding Reader Names fields in IBM Lotus Notes and Domino".
  
  
• Статья по Lotus на developerWorks "Производительность приложений Lotus Notes/Domino 7: Часть 1: Свойства базы данных и коллекции документов".
  
  
• Статья по Lotus на developerWorks "Производительность приложений Lotus Notes/Domino 7: Часть 2: Оптимизация видов базы данных".
  
  
• Статья по Lotus на developerWorks "Устранение проблем производительности приложений: Часть 1: Методики устранения проблем и советы по кодированию".
  
  
• Статья по Lotus на developerWorks "Устранение проблем производительности приложений: Часть 2: Новые инструментальные средства в Lotus Notes/Domino 7".
  
  
• Статья по Lotus на developerWorks "Настройка производительности приложений, Часть 1".
  
  
• Статья по Lotus на developerWorks "Настройка производительности приложений, Часть 2".
  
  
• Техническая рекомендация службы Lotus Support "Документы с Readers Fields не работают так, как ожидается в Directory Catalog".
  
  

• Загрузите пробную версию Lotus Domino с developerWorks.
  
  
• Загрузите пробную версию Lotus Notes с developerWorks.
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Блог developerWorks Lotus Team.

Об авторе

		Рафаэль Сейвир (Raphael Savir) занимается разработкой приложений для Lotus Notes/Domino и вопросами их производительности с 1992 года. Он имеет свою собственную консалтинговую компанию LS Development Corporation (http://www.lsdevelopment.com). Связаться с ним можно по адресу info@lsdevelopment.com.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало