Before talking about namespace security, we need to fully understand namespaces themselves. A brief discussion of the subject follows.
In a wiki, a namespace is a grouping mechanism. Namespaces are important when a large number of documents exist because they eliminate confusion. Consider a document named “return.pdf.” Is this a tax return, or does it describe Uncle Bob's trip home after a long exile in Africa? The document name doesn't make it clear. We could add more information to the document name, perhaps calling it “tax_return.pdf” to solve the problem. But what happens when two or more documents exist for the same reason–perhaps from different years or for different people?
One way to handle this problem is to continue including more information in the filename, such as “2008_tax_return.pdf”. While this is easy to do in a single-user environment, it doesn't work well in multi-user environments. Each user is likely to create his or her own documents using the same naming conventions, thus overwriting other documents or causing confusion. And the number of naming collisions will increase as time goes on.
So another strategy is needed…one that separates documents by something other than a filename. This is exactly what namespaces do. On a hard drive, a directory is a namespace. In the Java programming language, a package is a namespace. In a filing cabinet, a folder represents a namespace. And in a warehouse, a cardboard box represents a namespace.
Here is one possible way to structure the namespaces in a wiki. This illustration uses a single-user scenario for the purpose of discussion.
wiki root | *--personal | | | *--bills | | | | | *--2007 | | | | | *--2008 | | | *--family | | | *--hobbies | *--work | *--projects | *--sales leads
Notice there are two primary namespaces. These should be as mutually exclusive as possible. In other words–there should be no doubt as to which namespace a document belongs in. Our illustration's namespaces–home and work–are clearly named and non-overlapping. Proper naming strategies are essential.
Inside the personal namespace, the subnamespaces are related to subject matter. Although bills, family and hobbies might lead to some ambiguity 1), it is generally understood where documents should be stored. Perhaps more importantly: namespaces can be added or changed in the future to improve clarity.
Within the bills namespace, the subnamespaces are grouped by time period. This a very precise strategy since bills are normally dated.
The work namespace is a little vague–only 2 subnamespaces: projects and sales leads. What about research? What about miscellaneous information? What about sales leads that turn into projects in the future? This area needs more thought.
Now we turn our attention to security. How can we separate individual users from each other? How can we allow users to collaborate as a group yet remain independent from other groups? How do we maintain security over time as people move to different groups? These questions are addressed by Namespace permissions.
In Dokuwiki (as in many other multi-user products), there are 3 main concepts to understand: users, groups, and access control lists.
Lets illustrate namespace security with an example:
<draw name=namespacesecurity namespace=wikiisms>
The green bubbles on the right represent namespaces in Dokuwiki. Each namespace can point to a directory, a file, or a collection of either. For example, a namespace defined as
finance*.xls would refer to all Excel spreadsheets with the word
finance at the beginning of their filename. These are the groupings mentioned previously.
The middle column (in orange) is the interesting one. These are the roles (also called Access Control Lists, or ACLs) of the system. They are an abstract set of permissions that defines what a certain type of user can do, see, or edit on the wiki. Each role can be granted permissions to tailor their use of the wiki. For example, the
public ACL can be granted read-only permission to the
public namespace. Any member of this role will not be able to edit, nor will they see any content protected by another group permission.
The column of green bubbles on the left represent people with user IDs on the system. The bottom-most of these is the built-in group for non-logged-in visitors to the wiki–those who are just browsing. When this group does not have read access to the wiki, the site becomes a private one (meaning people must login before seeing anything). If the group does have read access but self-registration is disabled, the wiki takes on the flavor of a departmental system where only team members can edit. And if self-registration is enabled, the wiki becomes a public site for collaboration by anyone who cares to participate.
Wiki administration begins on the right-hand side of the diagram with the creation of namespaces. Then it proceeds to the center column where access control lists are created and namespaces are added to them. Finally, the administration panel allows the administrator to manage user IDs and assign them to zero or more ACLs.