FitNesse. UserGuide.
SecurityDescription [add child]

Security Overview

Pages can be marked with three levels of security:

secure-read Only authenticated users can read the page
secure-write Only authenticated users can write the page.
secure-test Only authenticated users can test the page.

These levels are not hierarchical. secure-write does not imply secure-read. Indeed, the three are completely independent flags that you can set on any page.

Setting Security

You set the security of a page by going to it's properties and clicking on the appropriate checkboxes. If none of the checkboxes are checked, then the page is completely insecure and anybody can do anything to it. This is the default.

Security Inheritance

Pages inherit their security from their parent pages. If a parent page has secure-read then all its children will be protected from reading, even though they don't have secure-read set themselves. There is no way to relax security in child pages. Where security is concerned, the parents rule.


Virtual Wiki

A virtual page inherits the security of its local parents, not its remote parents. This is a security hole for reading and testing. If the parent of a page has secure-read, but that page is accessed through a virtual wiki below the secure parent, then the security will be lost. Fortunately this is only true for reading and testing. Writing is never done over a virtual wiki, so it remains secure. At this point we're not sure whether this is a real problem or not. Let us know what you think.


The users and their passwords are supplied to FitNesse by using the -a as one of the CommandLineArguments.

SPNEGO/GSSAPI Authentication

See >SpnegoAuthentication