You Can View User Feedback To This Tip
Reader fields have been part of the Domino security architecture since the Mesozoic Era. Even so, they are not well understood by all Domino administrators and developers. This is unfortunate, since Reader fields offer one of the simplest, yet most powerful, security features of Domino and Notes. This short article will present an overview of Reader fields, so you will know where they might be helpful to you, mention some important side issues related to Reader fields, and provide pointers for further information.
SUMMARY OF READER FIELDS
Reader fields are Domino's per-document security method. In other words, Reader fields are used to grant (or deny) access to specific documents for specific users. The Domino server handles this work invisibly, so that users never see the documents they are not allowed to see. To implement Reader fields, you create a field (with any name) on the form and designate the field as type Readers. The contents of the field can be created in any way you want -- calculated when a document is created with the form, chosen manually by the document's author from a picklist, etc.
When a document has a Reader field, the Domino server will only show that document to users who:
a) have at least Reader access to the database in the ACL, and b) are listed in the Reader field of the document. Reader fields can also contain role names (and the roles can be assigned to groups) to provide great flexibility.
Reader fields are useful in many situations. For one example, imagine that you have a database which contains sales leads for all the salespeople in your company. But suppose that you don't want salespeople to see one another's leads. You can do this easily with Reader fields. Add a field named WhoCanSeeThis to the contact form. Set the field to type Readers and make it a Computed field in a hidden paragraph. Calculate the contents of the field (salesperson name) based on the first 3 digits of the Zip code (or however sales territories are assigned). Whenever salespeople open the database, they will see only their own sales leads. Leads in other sales territories simply will not appear in any view.
COROLLARY: USE REAL NAMES ON FORMS
A corollary to Reader fields is to use real Notes-style names whenever you include names in a form design. Then, if you later want to add a Reader field to the form, you already have the right names. To see how important this is, imagine that you don't do it. Suppose you have a field on a document with names like "Smith, John" and "White, Betty". If you want to add the Reader feature, these names will have to be translated (a potentially tricky process) to Notes-style names such as "John Smith" or "John Smith/ACME".
COROLLARY: DON'T ROLL YOUR OWN DOCUMENT-LEVEL SECURITY
Another corollary to Reader fields is to let Domino do this work for you. Some applications attempt to simulate the same feature by checking for document permission in a QueryOpen event. The QueryOpen code compares the user's name to a list of allowed names, then disallows the open event if the user is not authorized. There are several problems with this. The first is that there is no reason to write code for a feature that you can get with no coding! Second, a clever user probably can get around the security check, so your security is not very secure.
FOR MORE INFORMATION
Here is an article that presents a broad discussion about Domino/Notes Security, with one section dedicated to Reader fields:
http://www.notes.net/today.nsf/cbb328e5c12843a9852563dc006721c7/71102330e24a7ce5852564b5005e3682?OpenDocument
Here is a short sidebar to another article and also covers Reader fields well:
http://www.notes.net/today.nsf/625c2f03e734191a85256468005e76f6/f4268ab5fe50e95085256571006ef94f?OpenDocument
Also see the Domino R5 Designer Help (which comes with the Domino product), click on the Index view, then type "readers".
Chuck Connell is president of CHC-3 Consulting http://www.chc-3.com, a consultancy that helps organizations with all aspects of Domino and Notes, especially security.
USER FEEDBACK TO THIS TIP
- Just a quick addition to Chucks Reader fields Tip
I have found that if I am designing a database with access restrictions, it is
always wise to add a master reader field to all forms that contain security with
groups listed inside such as $All_Servers, or $Administrators.
The formula for this is simply:
"$All_Servers":"$Administrators" and this concatenate them in a list.
Make sure that you don't type:
"$All_Servers" + "," + "$Administrators" as this will simply enter a text
string, not a list.
Also it is best to leave other user restrictions in a seperate field. I have
made this mistake in my earlier days, and ended up locking myself out of
documents (as the reader field contains the text string
"$All_Servers,$Administrators" there is no group called this, so you will lose
access.
This way administrators have access to all the documents in the database and the servers have access to all the documents in the database (for agents etc..).
An alternate way is to create an application administrators group in the NAB,
add in the persons/servers who need access, then add this to the masterreader
field.
Hope this is of use.
Kindest regards
—Paul Thompson, A Senior Lotus Notes Developer in the UK.
- I'm not sure if this issue was corrected because I've never re-created the
problem but when I was developing under 3.3, using reader fields, I failed to
include the "Local Domain Servers" in the list of individuals with access. By
not adding "Local Domain Servers" in the Readers Field, it prevented our other
servers from seeing the document during replication. Once I added "Local Domain
Servers", the document replicated with no problem. If this was corrected at the
server level great! If not, it might be a good item to mention in case
developers plan to allow multiple users who reside in different servers.—Abner Morales
