The htmlOKay plugin enables the DukuWiki administrator to set permissions on embedded HTML access. Through its Embedded HTML Access Manager, it applies an extra layer of access controls on top of DukuWiki's built-in ACL. The ACL takes priority. Before users can embed HTML in a page, they must first have write access to that page.
The permissions allow for up to four levels of access and can be applied to both users and groups. htmlOKay requires the default setting for embedded HTML, which is that HTML is not allowed.1). Only users and groups which have been granted HTML access from within the htmlOKay Access Manager will have the right to use HTML in their files.
A file which supports embedded HTML can alternate between standard DokuWiki mark-up and HTML mark-up. HTML is included in a DokuWiki file by placing it between the two HTML tags:
=====Dokuwiki Standard Header===== <html> <H2>HTML Header</H2> </html>
Access levels determine the extent to which users and groups can use various features of HTML. There are two objectives:
Pages which enable embedded HTML inevitably run a security risk, not unlike pages which allow external files to be included by means of the include plugin. And pages with embedded HTML risk inadverently overriding the template's CSS or misaligning page structure. An unmatched <DIV>, for instance, inserted into the default template can remove all the formatting from the DokuWiki footer.
There are four access levels, each with increasing degrees of restriction. These are designated in the most obvious of terms as H, M, L, and U. That is, as High, Medium, and Low degrees of restriction, and a relatively Unrestricted degree.
It is also possible to set styles in the template's CSS files. The names of classes and id's referenced in the template's CSS files must follow the naming conventions described above.
The following tables detail the features which are allowed and disallowed and the restrictions placed on certain allowed features for several of the access levels.
Y = YES, the feature is allowed. N = NO, the feature is not allowed.
|FORM||N||Y||Y||Y||M and L|
|M||action, onsubmit||event listeners,captureEvent,createEvent, Ajax, location=url||ID's [#id_name]|
|L||action||event listeners,captureEvent,createEvent, Ajax, location=url|
Access permissions are set by namespace. That is, only one set of permissions can apply to the files of any one namespace. Various groups and users can be included in this set of permissions and they can each be assigned different access levels. Stated slightly differently, more than one group or user can have HTML access to the same file(s) or namespace, each with different access levels.
When applying permissions, the administrator has the option of applying them to ALL of the files in the namespace or to selected files in the namespace. Let us assume that there are 3 files in the namespace:
If the administrator selects ALL from the permissions menu, then the permissions will apply to all three files. But if namespace:our_policies is selected, then permissions for files in namespace apply only to namespace:our_policies. The other two files will not have HTML access. You cannot apply different permissions to different files in the same namepace. However, any user or group may have HTML access to the files in more than one namespace.
The inability to apply permissions on a file by file basis, as opposed to namespace basis, may be seen as a shortcoming. But the original idea behind htmlOKay was that the Wiki would be largely organized by projects and that each project would fall under its own namespace. The project would then be developed by a group or a single individual, who would be assigned an HTML access level.
Each page and/or namespace is assigned a display level. Normally, this is the same as the access level of the group or user who has created the page. But the Embedded HTML Access Manager will allow administrators to assign users and groups to the same namespace who have different HTML access levels for that namespace. Consequently, htmlOKay has a policy of applying the most restrictive permissions when a page is being viewed by an external visitor to the page, i.e. someone without HTML access to that page. If one developer has M access and another has L, the page will be displayed at M.
Moreover, if the user with L access uses features that are not supported by the M set of features, then those features will not work when M goes to add something to the page. It may not seem to make sense to apply more than one access level to a namespace, yet it can have uses when developing a project. We will look more closely at these issues when dealing with the Access Manager.