使用並理解 IBM Lotus Notes/Domino 中的 Reader Names 字段

利用並實現非常有用的 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 中所使用的同一個標準來允許/拒絕對單個文檔的訪問。另外，可以使用在 ACL 中定義的 [role]。
5. 加密。該特性可以允許/拒絕對個別文檔內部的個別字段進行訪問。可以根據用戶名稱或密鑰來進行加密，實際上用戶名或密鑰在 ID 文件之間是共享的。

 

儘管上述每個主題都很有趣，並且都值得關注，但是本文將重點討論使用 Reader Names 字段來保護數據。

如果使用 Notes 客戶機或 Web 瀏覽器的用戶對數據庫進行訪問，那麼假定他已獲得上述列表中的第三種訪問權。如果沒有采取其他任何安全措施（例如 Reader Names 字段），那麼從理論上講該用戶可以找到訪問任何文檔的方法。例如，通過在主視圖中不包含數據來隱藏數據（儘管從開發角度看很容易實現）並不能阻止決心找到該數據的人發現它。

基於對 Lotus Notes/Domino 中各種可用的安全措施的多年研究、測試以及使用，我們創建了表 1 來幫助您確定不同場合中最適合的安全措施。

注意：術語 “模糊 (obfuscation)” 用於表示通過在公共視圖中不顯示數據來隱藏數據，或通過使用 hide-when 公式來隱藏表單上的數據。這並不是真正的安全，但該方法在某些情況下很有用。

表 1. 比較不同的安全措施

安全類型	優點/缺點	實現方式
模糊	最適於向用戶隱藏數據，並且即使用戶設法找到了該數據，也不會發生任何財務或其他損失的情況。 易於實現且易於更改。 需要很少的開發經驗。 與 Notes 客戶機相比，更加適合 Web 瀏覽器。	使用表單字段上或導航選項上的 Hide-when 屬性。也可以使用 View Properties 框中的 hide-when 屬性來隱藏視圖。
Reader Names 字段	最適於可能發生財務或其他損失的情況。 擁有適當的訪問權限的代理可以通過編程方式訪問數據。 可用於允許複製，從而選擇性地將適當數據發送到不同的服務器/用戶。 儘管實現起來並不難，但是需要進行謹慎規劃，以避免出現 “丟失的” 數據，即正確用戶都無法訪問的數據。 如果某人獲得了數據庫的本地訪問權限，那麼他/她可以繞過 Reader 安全。 使用 Full Access Administration 模式的管理員可以繞過 Reader 安全（這通常認爲是好的做法，不過顯而易見，就像本地訪問一樣，它可能成爲缺點）。	藉助表單上 Reader 類型的字段是實現該安全措施最常用的方法。
加密	最適於可能發生財務或其他損失的情況。 即便是本地訪問也無法讀取加密的數據。 比較難於實現，更加難於更改。 複製時，無法利用加密的文檔來確定是否將數據複製到特定的服務器/人。 無法在視圖中訪問數據，也無法通過代理（即使 ID 擁有正確的訪問權限）以編程方式訪問數據。 Proprietary Notes 客戶機數據訪問。Web 瀏覽器既不能加密數據，也不能解密數據，以下特殊情況除外，即採用 IBM Lotus Domino Web Access 模板的電子郵件。	對適當的字段啓用加密，然後使用密鑰或公鑰進行加密，只有具有正確 ID 的 Notes 客戶機用戶才能訪問該字段。

從表 1 可以看出使用 Reader Names 字段比其他安全形式更具優勢。它們不但提供了真正的安全，而且如果具有適當的訪問權限（無論是使用 Notes 客戶機還是 Web 瀏覽器），還便於使用。嚴格地說，可以在視圖中查看數據，並且代理能夠以編程方式訪問數據。最後，該方式易於實現，並且如果將來需要更改安全或業務，也易於修改。

回頁首

實現 Reader Names 字段

若要使用 Reader Names 字段，通常在 Field Properties 框中將字段類型設置爲 Readers（參見圖 1）。這樣即可。使用用戶名稱、組或角色（本文稍後將進行討論）填寫這些字段後，只有指定用戶才能查看基於該表單的文檔。

圖 1. Field Properties 框

將該字段設置爲多值（multi-value）很有好處，這樣可以向字段添加多個名稱。如果使用該表單保存一個文檔，然後查看該字段屬性，那麼將看到 Field Flags 列出了 SUMMARY READ-ACCESS NAMES（參見圖 1）。這表示可以在視圖中查看數據 (SUMMARY)，而且它是 Reader Names 字段 (READ-ACCESS NAMES)。使用 Reader Names 字段時常見的錯誤是忘記爲該字段設置正確的類型，所以執行文檔屬性快速檢查是個不錯的方法，以便確認是否已進行正確設置（參見圖 2）。

圖 2. Document Properties 框

使用多個 Reader Names 字段

表單上可以有多個 Reader Names 字段。如果有一個以上該字段，那麼要確定誰擁有訪問權限，從所有 Reader Names 字段獲取累積名稱。另外，任何能夠編輯文檔的人都可以添加 Reader 列表（文檔屬性的最後一個附籤），然後該列表被存儲爲一個名爲 $Readers 的字段。如果添加了此類字段，那麼在確定文檔訪問權限時，將該字段視爲與其他所有 Reader Names 字段完全一樣的字段。

使用 Author 字段

如果創建了 Author 字段，那麼應具有 SUMMARY READ-WRITE ACCESS 屬性。有趣地是，如果文檔上只有 Author 字段，而沒有 Reader Names 字段，那麼任何人都可以查看該文檔。但是，只有擁有數據庫的 Author 訪問權限的用戶（該用戶列在 Author 字段中）以及擁有 ACL 中 Editor 訪問權限或更高級別訪問權限的用戶（無論其名稱是否在 Author 字段中列出）才能編輯該文檔。

但是，如果 Reader Names 字段也存在，那麼 Author 字段既可以用作 Reader 列表，也可以用作 Editor 列表。假定某人擁有 ACL 中的 Editor 訪問權限，但這兩個字段中都沒有列出他的名稱，那麼該用戶不能查看文檔，而且不能編輯文檔，即便他擁有該數據庫中所有文檔的 Editor 訪問權限。如果文檔的任何 Reader 字段或 Author 字段（每種類型的字段可以有任意多個）中存在該用戶名稱，該用戶就可以讀取並編輯此文檔。

也可以使用 LotusScript 以編程方式將此類字段添加到文檔，這種情形下，代碼如清單 1 所示：

清單 1. 示例 LotusScript 代碼

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

在這段代碼中，RNames 是 Reader Names 字段的名稱，NewValue 是字符串或字符串數組。在 Lotus Notes/Domino 的最新幾個版本中，Item.IsSummary = True 是多餘的；在早期的版本中，必須保證將新字段保存爲 summary 數據。

如果嘗試使用 @Formula 語言向文檔添加新的 Reader Names 字段，則不會爲其指定適當類型。而將其考慮爲文本字段。檢查文檔屬性，將看到 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 字段，但是不適用於純文本字段。

圖 3. 以規範格式存儲的 Reader Names 字段

如果將純文本名稱填入 Reader Names 或 Author 字段，那麼只要服務器和用戶擁有相同級別就能夠正常運行。例如，假定貴公司與其他公司合併，並且在不同級別的服務器之間複製了數據。假定其中一臺服務器稱爲 Apps/NorthEast/LSDevelopment，另一臺服務器稱爲 HQ/ACME。如果用戶嘗試訪問每個副本中的數據，而且其數據位於 Reader Names字段，而這些字段使用了用戶的純文本名稱，那麼他只能在 Apps/NorthEast/LSDevelopment 服務器上實現成功操作，因爲他僅與該服務器共享級別（其名稱中的 /O= 部分）。他可以通過交叉認證來訪問另一個服務器 HQ/ACME，但是 Reader Names 和 Author 字段沒有授予他訪問這些數據的權限。

從這裏得到的教訓是規範名稱最安全。永遠不要使用縮寫名稱，而且僅當您確信不會對數據進行跨公司或跨域複製時，才能使用純文本名稱。

回頁首

使用角色

注意：在本文中討論業務角色時，通常寫作 “角色 (role)”。但是，談及在每個 Notes 數據庫的 ACL 中顯示的特性時，將使用 [role] 以示區別。

首次使用 Reader Names 字段時，嘗試將需要訪問文檔的每個單獨用戶的名稱填入該字段中。但是，這不切實際，因爲如果用戶在公司內部更改業務角色時，必須在很多（也許是成百上千）文檔中替換其名稱。雖然肯定能夠作到準確無誤地進行替換，但是除非別無選擇，否則您肯定不希望出現這種情形。在很多公司中，經常發生這種情況，因此您需要爲此做好準備。

此外，Reader Names 字段可能涉及一大羣人。例如，公司中的 30 位主管和經理都需要查看應用程序中的銷售數據。爲每個文檔重複輸入這些名稱是對空間的浪費，當然，名稱愈多，就需要愈頻繁地更改名稱列表。最後名稱列表超出了字段的 32K SUMMARY 數據限制，雖然這是罕見情形，但您肯定有所耳聞。

更可取的做法是儘可能使用組或 [role]。從理論上講兩者都符合要求，不過實際上應儘可能使用 [role]。可通過以下方式來考慮組和 [role] 之間的區別：組是在 Domino Directory 中維護的。存在數以千計的組，如果貴公司與其他公司合併，那麼這些組的名稱可能發生更改，並且總有可能發生該目錄被破壞或其他您一個人無法解決的問題。圖 4 展示了將角色指定給用戶 Rafael Savir/Boston/LSDevelopment 的 ACL。

圖 4. 將 [role] 指定給用戶的 ACL

另一方面，[role] 是特定於應用程序的。通過在 ACL 中執行一些單擊操作，可以將 [role] 應用於一個組或多個組。可以取消一個組的 [role] 並其應用於其他組，必要時，也可以在 ACL 中將 [role] 應用於個別名稱。曾出現過目錄被破壞的危機情況，但是通過將用戶名稱臨時添加到 ACL 並將相關 [role] 應用於用戶名稱，就能爲用戶授予對關鍵數據的訪問權限。如果 Reader Names 字段使用組而不是 [role]，則不可能實現上述操作。

若要以這種方式來使用 [role]，請考慮需要訪問安全文檔的組。假定這些組如下所示：

• 執行委員會 (Executive Committee)
• 人力資源代表 (HR Reps)
• 銷售管理團隊 (Sales Management Team)

 

可以用兩種方式來解決如何爲這些人授予權限的問題。一種方式是爲每個組設置一個 [role]，另一種方式對這三個組設置一個 [role]。這取決於具體情形，但是由於可以擁有多達 75 個 [role]，所以通常可以自由選擇如何創建並應用它們。基於多年來使用 [role] 進行應用程序開發的經驗，我們編制了以下適用的指導方針。這些並不是絕對準則，但是在每種情形下，應用這些方針都能預防發生問題：

1. 保持其簡短。這將節省磁盤空間，而且便於您正確拼寫代碼中的 [role]，隨着時間的推移，這將成爲必需的。
2. 不要使用空格或其他不常用的標點符號。這也便於正確拼寫，另外還能避免在執行全文搜索時發生問題，並且如果必須通過 URL 傳遞 [role]，這也能避免 Web 應用程序中可能出現的問題。
3. 可以模仿組名稱，但是請注意隨着時間的推移，組名稱可能發生更改。
4. 始終爲開發人員和/或管理員至少保留一個 [role]。換而言之，如果有一個名爲 Development 的組，不要簡單地將 [role] 命名爲 [Dev] 或 [Development]，因爲該 [role] 可能用於實際正在開發該應用程序的 Notes/Domino 開發人員。對於其他組，可以使用 [ProdDev] 之類的 [role]。

 

因此，本例子中將創建帶有以下 [role] 的 Reader Names 字段：

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

 

請注意，由於添加了最後兩個 [role]，因此所有開發人員和管理員都可以訪問這些數據。

回頁首

Reader Names 字段在複製、代理和視圖中的作用

現在瞭解了應該以何種方式設置 [role] 和 Reader Names 字段，下面將花費幾分鐘時間來考慮一下其他的數據訪問方式。具體而言，我們發現在文檔上應用 Reader Names 字段後，複製、代理和視圖有時可能發生意外行爲。本節內容將深入研究各種情形。

複製

如果跨服務器進行數據複製，那麼惟一需要注意的事情是在 [Admin] 角色中包含所有服務器（如前所述）。可以通過 LocalDomainServers 組來實現，這樣能保證域內的所有服務器可以查看數據庫中所有受 Reader 限制的文檔。

如果不希望將所有數據複製到所有服務器，那麼需要更改此方法。大型銷售應用程序就是這樣的一個例子，其中每個地理區域僅維護本區域的數據以便簡化性能。在這種情況下，可能使用例如 [Servers-APAC]、[Servers-EMEA] 等 [role]，並按照地理區域將這些 [role] 應用於文檔，然後應用於 ACL 中的個別服務器名稱。仍然需要謹慎，以免不小心通過 LocalDomainServers 或其他一些組授予所有服務器訪問所有數據的權限，因此制定此類模型之後應小心地進行測試。

更頭疼的問題是對本地複製的影響。例如，假定 20,000 名銷售代表每人有一臺筆記本電腦，並且每晚對自己的數據進行本地複製。如果沒有 Reader Names 字段，可能會擔心發生複製/保存衝突，不過僅此而已。如果使用 Reader Names 字段，還可能擔心本地副本與服務器副本不同步，例如同時在本地副本和服務器副本上編輯文檔，而在服務器上的編輯包含從 Reader Names 字段刪除該用戶名稱。

換句話說，如果在進行編輯時兩個副本中有一個不能訪問所討論的文檔，就無法解決複製衝突問題。結果是服務器、本地副本各自保留自己的編輯，而二者都沒有意識到它們已經不同步。對於該問題，沒有簡單的解決方案，因此在設計整體架構和工作流時應特別注意這一點。

代理

Reader 安全對代理的影響其實很簡單。如果代理是由用戶觸發的，例如通過單擊按鈕，那麼代理在運行時就好像是用戶在執行操作。如果該用戶擁有文檔的訪問權限，則代理也擁有文檔的訪問權限。如果用戶沒有所討論文檔的訪問權限，那麼在代理工作時將顯示錯誤（例如，“Entry not found in index” 或 “Unauthorized to attempt that operation”）。

如果是按照計劃運行的代理，則代理在運行時就好像是代理的簽名人，除非填寫了代理的“Run on behalf of”字段，填寫該字段後，代理在運行時就好像是用戶（參見圖 5）。

圖 5. Agent Properties 框

視圖

出於功能性和性能考慮，對用戶影響最大的方面可能在於視圖。

如果對視圖進行了分類，那麼用戶可能會看到有點古怪的類別，但無法查看該類別內的文檔。這對於用戶來說是很常見的問題。一種解決方案是使用 Show single category 選項（參見圖 6）來創建嵌入視圖，並且讓用戶從其擁有訪問權限的類別列表中選擇要顯示的類別。這樣用戶不會看到其他類別，所以不會出現空視圖。Web 瀏覽器可以不着痕跡地實現該功能，並且該功能也可以用於 Notes 客戶機。另一種解決方案是重新考慮劃分類別，以便用戶不會看到空類別。

圖 6. Embedded View 下的 Show single category

與其他方式相比，Reader Names 字段會使視圖執行速度慢很多，因爲服務器必須檢查每個文檔以確保其可以被查看。必須對每個用戶執行該操作，因此如果有很多併發用戶以及很多帶有 Reader Names 字段的文檔，那麼服務器/應用程序的速度可能顯著減慢。當很多用戶擁有對視圖中一小部分文檔的訪問權限時（銷售或 HR 應用程序中可能出現這種情況），尤其如此。最佳解決方案仍然是使用 Show single category 來創建嵌入視圖。通常這比打開文檔上完全沒有 Reader 限制的原始視圖要快。

另外，可以對視圖進行分類，而且開始時摺疊視圖。這將提高速度，儘管可能會導致前面討論過的問題；即用戶可以看到類別，但是在該類別中看不到任何文檔。在某些情況下，將數據分解到多個視圖中並將用戶引導到正確視圖很有意義。例如，如果用戶單擊導航中的 Regional Sales，而您可能有一個檢查 @UserRoles 的公式，就會打開適當的視圖 Sales-US、Sales-APAC 等。

有關視圖性能的更多信息，請參閱 developerWorks Lotus 文章 “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 安全。

圖 7. Full Access Administration 選項

回頁首

結束語

希望本文有助於儘可能輕鬆高效地計劃和實現 Reader Names 字段。它是個卓越的特性，也是個很好的安全措施，並且只要提前配置好各方面內容，就很容易實現和維護。只需要記住關鍵的一點：提前配置各方面內容。如果這樣做了，則您在使用 Lotus Notes/Domino 中的強大特性時，將獲得完美體驗。