JohnV brought this text back from the grave as the security subsystem discussion/development has gotten some new life. THis page filter was written and briefly tested/played-with before being abandonded. We needed the security to cover more than just basic page view and edits (like view or upload attachments) so we dropped this as a failed experiment. One take-away from this experiment was that using wiki pages to define the groups, and using the page attributes mechanism for default and page level permissions really does work okay.

Consider this all trash for now. The code for this is now present in the McKessonApsWikiPlugins jar file for the morbidly curious.


The authorization mechanism introduced in the JSPWiki 2.x era was a step towards adding good security features, but did not go far enough, it added the security checks to the jsp pages themselves, this let it be more easily changed and customizaed, but left some 'holes' in the security. Notably the use of the InsertPage plugin or any XML-RPC based access like (TranscludePlugin) bypasses the security. These can be patched, and are infact now patched.

Due to how PageFilters are implemented in the wiki engine, they cannot be bypassed, so they make a natural spot where authorization can be performed. This pagefilter can be used to prevent VIEW or EDITs of wiki pages, it throws a RedirectException if the current user is not permitted. (or could return a benign 'not permitted' string.)

Simply, this filter uses the UserProfile.getLoginName() value and looks to see if that name is in the set of results returned by a query (yes it uses the QueryPlugin at it's core).

You provide the basic parameters via your 'filters.xml' file. All are optional, defaults are indicated below:

  • 'nullUserProfileLoginName', if there is no current user, this name is used, defaults to 'UnknownUser'
  • 'allAccessUserName', defaults to ' ', this username cannot be blocked from VIEW or EDIT by any means.
  • 'viewBlockedMessagePage', if a view is blocked, redirects to this page, defaults to 'NotAuthorizedToView'
  • 'editBlockedMessagePage', if an editis blocked, redirects to this page, defaults to 'NotAuthorizedToEdit'
  • 'defaultDenyEditRule', defaults to 'BY []' (no-one denied.)
  • 'defaultDenyViewRule', defaults to 'BY []' (no-one denied.)

Each page can override the defaults for a given page by using the [{SET}] directive on the page. This sets a page attribute which if present is used instead of the default rules. This filter will use the page attributes DENY-EDIT and/or DENY-VIEW if they are present on a page, otherwise it uses the defaults from the 'filter.xml'

Here are two examples of what a use of [{SET}] might look like...#

  • Explictly list the people who are to be DENIED...
    • [{SET DENY-EDIT='BY [ListOfUsersBlockedFromEditing]'}]
    • [{SET DENY-VIEW='BY [ListOfUsersBlockedFromViewing])'}]
  • List the users who are to be ALLOWED, then negate it for the rule...
    • [{SET DENY-EDIT='NOT (BY [ListOfUsersAllowedToEdit])'}]
    • [{SET DENY-VIEW='NOT (BY [ListOfUsersAllowedToView])'}]

Of course the query syntax shown above or something similar could be put in 'filters.xml' for the default rules.

Special Features#

The filter prevents you from blocking VIEWs of the 'viewBlockedMessagePage' and 'editBlockedMessagePage' so you don't cuckold yourself.

There is provision for specifying an 'allAccessUserName' that cannot be blocked from VIEW or EDIT by any means. This way there is always one user who can get in and fixup a screwup in the security configuration.

If for some reason the WikiContext.getPage() is null, it allows the access; the page should never be null, but if it is this filter just returns to allow the access.

A user is always allowed to VIEW thier own page. e.g. User JohnSmith cannot be prevented from VIEWing the page 'JohnSmith'.




  1. Does not do anything with attachments, just not possible with a page filter approach.
  2. Does not address the new delete functionality that some PageProviders may supply.


As usual please keep most discussion on AuthorizationPageFilterDiscussion.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-29) was last changed on 26-Dec-2007 00:20 by