Current development on JAMWiki is primarily focused on maintenance rather than new features due to a lack of developer availability. If you are interested in working on JAMWiki please join the jamwiki-devel mailing list.

Tech:User Permissions

ktip.png This page (and all pages in the Tech: namespace) is a developer discussion about a feature that is either proposed for inclusion in JAMWiki or one that has already been implemented. This page is NOT documentation of JAMWiki functionality - for a list of documentation, see Category:JAMWiki.
Status of this feature: IMPLEMENTED. This functionality has been implemented using Spring Security, starting with JAMWiki 0.5.0.


User and group permissions are probably the feature most lacking in JAMWiki for corporate users. The delay in implementing this functionality is due mainly to the desire to ensure that any user/group permission framework is flexible and integrates well with existing code, and to avoid imposing ill thought out schemes on new wikis that should make minimal use of permissions. Considerations to bear in mind with any such system:

  • Apache Tomcat 6 supports very effective and proven password protection and wherever possible users should be relying on this, not on the wiki code, to make privacy decisions. It should be easy to set up Tomcat 6 and jamwiki for single login, and to assign the wikis to different domains with simple URLs.
  • When finer grained permissions than use/can't are required, usually setting up multiple virtual wikis is the best way. Integration between permissions and this feature is essential - a virtual wiki is simply a wiki with disjoint access rules, though the groups and users for both might be exactly the same.
    • Nesting/framing pages from one wiki into another (as Wikinfo does) is critical for corporate and sophisticated users, so it should be possible to delegate the permissions or challenges explicitly to the other wiki to verify some user - a low security level allows the alien wiki to assert who the user is, a higher one requires re-verifying, the highest requires this to be done by the wiki hosting the page. Rules for framing whole categories or namespaces or patterns of page names need to be integrated into permissions if only for this reason.
  • Inter-relationship of groups, namespaces and categories must be intelligently defaulted, straightforward and thus hard to exploit - suitable out of the box for a low-traffic public site; It should be easy for newbies to manipulate permissions by changing categories and moving pages into/between namespaces; Using per-page permissions should be strongly discouraged as they inevitably lead to complex poorly thought out schemes that prevent collaboration, and warnings should accompany any such attempt.
  • Any use of permissions per page, separate from the virtual wiki, namespace or category system, should be strongly cautioned and usually discouraged by providing good examples of how to achieve the same goals by the means above. Most users abuse detailed permissions. Many destroy their own projects by making it very difficult to participate or collaborate. Designing proper group/user permissions is difficult and any failure to anticipate a need for two users to collaborate on a page or set of pages will lead to one user doing things "for" another, or transactions that should take place within the wiki taking place outside it and leading to incomplete version history and inability to discover what motivated changes.
  • By default all per-page features must be off. While it initially appears like a good idea to most users to make pages non-writeable by default, it almost never is. The situation is analogous to browsers where turning off Java, Javascript, all use of cookies, etc., will make you somewhat 'safer' but will prevent most sophisticated sites from working at all.
  • Only when all the above design considerations are solved should it become a priority to find a technology that can extend the methods suggested above:
    • It must integrate well with the Acegi framework that is used by JAMWiki, and preferably utilize as much native Acegi functionality as possible.
    • It must be manageable using a web interface. An admin screen should be created that allows users to be assigned to groups, and permissions to be assigned to users and groups.
    • There must be a flexible way to assign permissions/roles to actions. For example, it should be possible to create a "translator" permission/role and to then require that anyone accessing Special:Translation have the translator permission/role.
    • Ideally groups should be able to have sub-groups, so that group A could have a set of permissions, group B could have a different set of permissions and parent group AB would automatically inherit the permissions from both groups A and B.
    • Ideally groups should be easy to create/tie to Apache's own user groups. As noted above this should be the default: Inherit the entire Apache group.
      • If page visibility is restricted for some IP number or account, Apache should be logging multiple attempts to reach the page and treating them as it does exploits. This is impossible if jamwiki draws a page for that account or IP and treats it as a normal user.

Security concerns in general belong in apache, not jamwiki, wherever possible.


Based on the above, a standard ACL system might be the best option, although other ideas are welcome.

ACL has the huge advantage that it's already well understood. It has many disadvantages but none that can really overcome this. Such as no integration with the multiple-wiki/category/namespace system.

How it might work[edit]

Some simple examples of how the permission system might work:

  • There should be a translator group, and members of this group should be able to access Special:Translation.
  • There should be an admin group, and members of this group should be able to access Special:Admin and Special:Maintenance.
  • Logged-in users should potentially be members of a logged-in user group. It might then be possible to protect certain pages so that they are read-only for non-logged-in users.

More complex examples illustrating how multiple features might interact and why Apache integration and forms to deal with exceptions/events/warnings/verifications are critical:

  • Some pages are about corporate internal finances and specific business operations. These are in [[:category:MegaCorp internal]] though they may also be in other categories. These should be restricted to internal users, with collaborators able to ask permission to see specific pages via a simple form. If granted, they'll then be able to see only that one page. Or, alternatively, internal information AND THEN the category tag can be removed from that page, so that collaborators can read it. This does not require any interaction with the permission system, any user within the internal group can do it, though of course their action will be recorded in the history. Changes to categories that imply changes in permissions require captcha and an extra login verification so that no one does this by mistake.
  • The legal department has a parallel "legal:" namespace beside every page to keep legal concerns with particular ideas or discussions separate from other discourse. Pages that appear in this space have predictable names, but only people the legal department considers to have legal expertise can edit them. Only legal and project managers can read those pages. If they consider it important for anyone else to read the page or any content from it, they must copy that content to a page not in the "legal:" space that those users can read. They can link to the legal page and anyone who tries to read it gets a form to request access to the legal opinion. If granted they get the current state of the page emailed to them. They never see the page history. It's up to the lawyers themselves whether to use their own names or obscured ones, or shared credentials (like "corporate_legal_department") to identify themselves.
  • A semi-public wiki run by a consortium like IETF or W3 or Java itself needs to hold a current editable version of its specifications and internal documents but these must reference and annotate official versions hosted elsewhere in XML and also import widely-read definitions of key concepts from Wikipedia or Wikinfo (which allows rewrites of concepts by their promoters, moving critical views to a different page). They need multiple virtual wikis that mirror these external ones (by whatever means), and they need one set of user permissions that mirror their own internal administrator, member, committee and other status. Using these permissions, members should be able to decide which sources to rely on for which information, modifying the pages that control the XML or other imports. Anonymous public users can ask questions by editing talk pages or user talk pages, and can link to any concept defined in Wikinfo or Wikipedia, but when clicking on that link the more priveleged users see the internal, not external, version of that page, with a one-liner warning that the person linking probably means the current page or a recent page in the public source. This ensures that anyone who responds to such a question or comment has the best possible internal view of that topic or goal or technology, since it's maintained by all the insiders in common.
  • A public commercial wiki hosts what amounts to ads. It has a parallel name space "revenue:" to record the revenues from each page and where they come from. It lets any user edit pages that have under one dollar per week revenue. Any edit by insiders with accounts is treated as a bet that they will attract more revenue with the edit - they pay a penalty if the revenue drops after their edit. Pages that do not generate revenue can be edited freely but once they generate over a dollar per month, the insiders that edited it to that point have the right to take that content to another domain they own and the wiki will redirect for a percentage of the revenues. They can create that redirect with a simple form that agrees to this arrangement and sets up hosting for their new domain. Or, they can keep working on pages within the wiki but if revenues fall below a dollar per week they lose the right to take it to their own site. Permissions vary based upon the revenue, and change once per week when a program updates the revenue page with numbers.

Relationship to categories and namespaces[edit]

Groups could/should be linked to categories and namespaces by default, on the assumption that a category represents a range of topics and that a namespace (or any page name with a colon in it, not just hardwired namespaces) represents a point of view. By default the permissions assigned would allow reading but not writing, the most common request. Since you can't add new categories to a page, nor remove them, nor change the name of a page without write permission, to make it visible and/or readable someone with the permission must remove the category or change the name, i.e. copy the page, which they can of course do anyway.

The great advantage of this scheme is that it instantly supports main namespace readable and editable by anyone, with a number of parallel (talk) and complementary (user, project) namespaces writeable only by their users. This lets a public wiki grow and attract users interested in participating on the deeper (talk, user, project) level. It's also easy to make talk pages or user pages or project pages unreadable by the anonymous (not logged in) group.

Tikiwiki-based services often make good use of permissions but most of them have overused them to the point that they can't grow. This is a mistake.

It makes more sense to provide out-of-the-box defaults sufficient for a public wiki with some need for private debate, so that anyone using the group permissions gets an instant tutorial in how to responsibly use permissions. Which usually means, minimally using them.


I haven't done any work on this in a while, but tonight I threw together a design for the schema. This is different from what's in Subversion currently, but it doesn't change the schema used in any previous JAMWiki releases:

    CREATE TABLE jam_role ( \
      role_name VARCHAR(30) NOT NULL, \
      role_description VARCHAR(200), \
      CONSTRAINT jam_pk_role PRIMARY KEY (role_name), \
      CONSTRAINT jam_unique_role_name UNIQUE (role_name) \

...holds role name and description.

    CREATE TABLE jam_role_map ( \
      role_name VARCHAR(30) NOT NULL, \
      wiki_user_id INTEGER, \
      group_id INTEGER, \
      CONSTRAINT jam_pk_role_map PRIMARY KEY (role_name, wiki_user_id, group_id), \
      CONSTRAINT jam_fk_role_map_role FOREIGN KEY (role_name) REFERENCES jam_role(role_name), \
      CONSTRAINT jam_fk_role_map_wiki_user FOREIGN KEY (wiki_user_id) REFERENCES jam_wiki_user(wiki_user_id), \
      CONSTRAINT jam_fk_role_map_group FOREIGN KEY (group_id) REFERENCES jam_group(group_id) \

...holds the mapping of user to role. Additionally, in the initial implementation there will be two groups for anonymous & logged in users that are automatically assigned to users.

    CREATE TABLE jam_group ( \
      group_id INTEGER NOT NULL, \
      group_name VARCHAR(30) NOT NULL, \
      CONSTRAINT jam_pk_group_id PRIMARY KEY (group_id), \
      CONSTRAINT jam_unique_group_name UNIQUE (group_name) \

...a simple (for now) table that will hold the anonymous & logged-in groups referenced previously.

Values in these tables will be used in default installations to provide the necessary GrantedAuthority[] array for a user. For installations that use a non-default implementation they are still free to implement their own permissioning scheme. Configuration of how roles are used (for example, to block file uploads or prevent users from viewing admin pages) is controlled via the Acegi configuration file, and that code has already been committed to Subversion.

This seems fairly straightforward, but please add a comment if there are any concerns or other issues. -- Ryan 27-Jun-2007 23:11 PDT

The above proposal is now implemented in the Subversion code with a few very minor modifications. The UI for displaying current roles on the Special:Roles page is still not completely functional, but hopefully I'll get that finished soon. -- Ryan 01-Jul-2007 22:50 PDT



I've started an implementation for JAMWiki 0.6.0 based on feedback from User:swift. The basic design is that each pages to be protected can be assigned roles through the Acegi configuration. For example, Special:Admin is given ROLE_ADMIN, Special:Translation is given ROLE_TRANSLATION, Special:Edit is given ROLE_EDIT, etc. Users can then be assigned roles from Special:Roles. This will allow (for example) specific users to be assigned access to the Special:Translation page without the need to give them access to the full set of admin tools.

In addition, while a full implementation of "groups" may not happen for this release, two default groups for logged-in and non-logged-in users will be created. When a user visits the site they will automatically be assigned any roles given to the non-logged-in group, and upon logging in they will gain the roles assigned to the logged-in group. This will allow site admins to prevent non-logged-in users from viewing pages, editing, or whatever else they might choose to do.

Barring any objections my plan is that user roles will be stored in a jamwiki_user_roles table. I know that some sites interface with external systems such as LDAP to handle permissions, so if anyone has ideas on how to handle this better please let me know, bearing in mind that I don't have an LDAP server or other authentication system to test with. -- Ryan 15-May-2007 21:44 PDT



Can someone please outline the status? As of JamWiki 0.5.2, I'm unable to prevent anonymous users from editing pages.

The label needs to be changed, but check the box for "Force the setting of username" to require login for editing. -- Ryan 07-Mar-2007 08:35 PST

Controlling Users[edit]

Moved from the Feedback page:

Have JAMWiki up and running on Ubuntu 6.06 with Tomcat and MySQL - all pretty painless!

  • Is it possible to control user access?
I am wanting to limit access to only certain folk and it appears that presently anyone can register and have access
  • How does one remove users?

-- Colin

Hi Colin - thanks for the feedback! If you'd be willing, I'd be grateful if you could list your configuration on the Supported Configurations#Known Working Configurations page. Regarding limiting user access, at the moment there is an option to force users to login before editing (see the admin screen), and any page can be made read-only (also through the admin screen) but those are the only limits that can be placed on users. A future version of JAMWiki could definitely include greater limits - what exactly are your needs? Would something like the following suffice?
  • Add an option to disable user registration.
  • Add an admin screen for creating and managing users (including deleting users).
  • Add an option to force login before viewing pages.
If that works then feel free to add it under Roadmap#Unscheduled. It probably won't be a top-priority item (there is a ton of stuff on the to-do list), but eventually that could probably be implemented. Thanks again for the feedback. -- Ryan 15-Jul-2006 09:27 PDT
I have a similar need/desire. I went as far as to start implementing it one night back in the 4.3 codebase. I added an option on the admin page to disable the "register" link for non-admin, added code to not render the link. Testing seemed to show that data for the option was not yet available when the jsp containing the register link was being executed. Never got the chance to get back to this.
Not discounting my own screwup, would you expect this behavior?
nomead 25-Jan-2007 05:28 PST
Was Colin's question of "How does one remove users?" answered beyond the plan for a user admin screen? I have 0.8.0 installed, and discovered a few "lurkers" that may have nefarious intentions (based solely on google searches for the email addresses used; one seems to be a spammer for "wife swapping/swinging"). Any chance that we can have some SQL? Tim--7-Dec-2009
Here's some SQL that should do the trick (written for version 0.8.0). The caveat of course is that you're directly modifying the database, so use at your own risk. That said, it worked for me on a test instance.

update jam_recent_change set wiki_user_id = null where wiki_user_id in (select wiki_user_id from jam_wiki_user where login = 'guest');
update jam_file_version set wiki_user_id = null where wiki_user_id in (select wiki_user_id from jam_wiki_user where login = 'guest');
update jam_topic_version set wiki_user_id = null where wiki_user_id in (select wiki_user_id from jam_wiki_user where login = 'guest');
delete from jam_watchlist where wiki_user_id in (select wiki_user_id from jam_wiki_user where login = 'guest');
delete from jam_log where wiki_user_id in (select wiki_user_id from jam_wiki_user where login = 'guest');
delete from jam_group_members where username = 'guest';
delete from jam_authorities where username = 'guest';
delete from jam_wiki_user where login = 'guest';
delete from jam_users where username = 'guest';

- Ryan • (comments) • 07-Dec-2009 21:07 PST
Is this SQL still valid in the 1.2.x code line and schema? I have neglected my wiki for a while, but will be resurrecting it for some more gaming on the horizon. In my absence, I've gotten a lot of spam registrations than I need to purge.
-- Tim • (comments) 31-Jul-2012 08:56 PDT
I used the following successfully yesterday, although I'd suggest enabling rollback just in case anything goes amiss, and you'll need to flush the cache (from Special:Maintenance) after directly modifying the database. This SQL assumes the spam accounts didn't make any edits, otherwise it will fail due to dependencies on jam_topic_version:
delete from jam_recent_change where wiki_user_id = 2980;
delete from jam_log where wiki_user_id = 2980;
delete from jam_authorities where username in (
  select login from jam_wiki_user where wiki_user_id = 2980
delete from jam_group_members where username in (
  select login from jam_wiki_user where wiki_user_id = 2980
delete from jam_users where username in (
  select login from jam_wiki_user where wiki_user_id = 2980
delete from jam_wiki_user where wiki_user_id = 2980;
-- Ryan • (comments) • 31-Jul-2012 09:33 PDT
Boo... didn't work. PostgreSQL 8.2.4, jamwiki 1.2.3 (10/4).
-- Executing query:
delete from jam_recent_change where wiki_user_id = 16;
delete from jam_log where wiki_user_id = 16;
delete from jam_authorities where username in (
  select login from jam_wiki_user where wiki_user_id = 16
delete from jam_group_members where username in (
  select login from jam_wiki_user where wiki_user_id = 16
delete from jam_users where username in (
  select login from jam_wiki_user where wiki_user_id = 16
delete from jam_wiki_user where wiki_user_id = 16;
ERROR:  update or delete on table "jam_users" violates foreign key constraint "jam_u_wuser_users" on table "jam_wiki_user"
DETAIL:  Key (username)=(alopaxyposTex) is still referenced from table "jam_wiki_user".

********** Error **********

ERROR: update or delete on table "jam_users" violates foreign key constraint "jam_u_wuser_users" on table "jam_wiki_user"
SQL state: 23503
Detail: Key (username)=(alopaxyposTex) is still referenced from table "jam_wiki_user".
Any other ideas? Update swapping the last two lines did the trick, but I also looked at the schema. jam_wiki_users foreign key does not permit cascade. I've considered altering that in my instance. Backup on hand of course (the upgrade from 1.1.2 > 1.2.3 was flawless).
-- Tim • (comments) 19-Oct-2012 12:52 PDT
Hopefully the Honeypot and other spam tools in 1.2.3 will help you avoid some of the spambot issues - gets far fewer spambots since enabling Captcha for registration and the Project Honeypot validation. I'm not enough of a database expert to know if a cascade option is feasible across all databases that JAMWiki supports, but if it works in your instance (and if you have a backup) then I'd say go for it. -- Ryan • (comments) • 21-Oct-2012 17:53 PDT
I have recaptcha on (since 1.1.2?) Most of my spambot issues appear to be manual captcha bypass. My neglect has over 600 spam accounts. I really liked how the old SQL seemed to purge them from existence. The new SQL not so much, but some good work there (more than I'm willing to say I have experience crafting in SQL). I would love, love, to see a User Purge feature, something that would remove spammers from the collective record. I'm curious if I go through and delete revisions of these users if the jam_topic_version limitation could be hurdled? I'm looking into project honeypot for additional help with spam. -- Tim • (comments) 22-Oct-2012 10:15 PDT
Bearing in mind that I'm sleep deprived and may not be understanding something obvious, could you give a bit more detail on what you mean by "data for the option was not yet available when the jsp containing the register link was being executed"? I haven't actually tried anything similar myself, but without actually looking at the code I can't think of any reason why hiding the register link should cause any problems. Nothing like that has yet been implemented because there didn't seem to be a high demand for such a feature, but if it's something people would like to have I'd be glad to start a Tech: page about what should be required, and to solicit ideas for how people want to see the implementation done. -- Ryan 25-Jan-2007 22:07 PST
=)) - got me. Too lazy to look back over the code when I read the comment and responded. I will take a look at this again and see if I can make it work. If not I'll be back. I do think that this is an important feature - I think that Tom (below) has the right idea for the long term. For my purposes admin-controlled registration is sufficient. I'll let folks know.
nomead 26-Jan-2007 19:50 PST
Since I really fear spam flooding our Wiki (also, in Germany the provider is liable for offending content entered by users; at least for forums), I would find it very useful, if
  • a user would require a double-opt-in to start editing and/or
  • new users automatically will be in a moderated state, changes will only shown to them and could be granted or denied by power-users (e.g. admin) until they got switched to the can-edit-state. Tom 2007-01-26
Just a note to say that I'm not ignoring this discussion, but a proper response requires more thought than I'm capable of at the moment. I'll see if I can put together some coherent thoughts on the subject over the weekend, and would encourage anyone else who has comments or suggestions on this issue to please add them. -- Ryan 27-Jan-2007 01:52 PST

I have problems on my Wiki where users are coming in and uploading pronography on new pages. All the important pages are locked, but I can't seem to stop new pages being created by non admin users. Is there anyway to acheaive this.

Its quite important to me as the site is an old pupil network for my old school. Its quite likley some of the current pupils will visit the site. At present the recent changes page has adult content on it. I have deleted it but the contents title is still on the recent changes page. Is there any way to remove all traces of it?

--Charlie 16-Jun-2007 11:34 BST

Spam unfortunately became a problem for JAMWiki faster than I expected. I've belatedly started documenting some of the features available to address the problem at Configuration#Handling Spam and will try to update it further this weekend. Short summary: the ability to block certain file-type uploads is available, and I've found that blocking ".htm" and ".html" on has helped a lot. In addition, there is a regular-expression based blacklist (it is in your installation at /WEB-INF/classes/spam-blacklist.txt) that holds patterns that will be blocked when text edits are made. Once the spam-blacklist.txt file is updated you must either restart your app server or click on the "Reload Spam Filter Patterns" from Special:Maintenance for the changes to take effect.
As to removing deleted entries from the recent changes pages, at present there is no easy way to do so. You can either manually delete them from the jam_recent_change table in your database ("delete from jam_recent_change where edit_type = 5" will get rid of all recent changes for deleted entries) or else you can manually add code to the /WEB-INF/jsp/recent-changes.jsp file to suppress display of deletion history. If you choose that approach, the changes to make are:
AFTER the line that reads:
<c:forEach items="${changes}" var="change">
<c:if test="${!change.delete}">
And BEFORE the line that reads:
Note that neither of these approaches are supported officially, you may need to do them again after an upgrade, make sure you backup any file prior to changing, yada yada yada gotta cover my ass. That disclaimer aside, they're both fairly simple changes that should address your issue, and if you add a reminder and a description of what the feature you need on either the Feedback or Roadmap pages I'll try to get an admin option to allow hiding deleted entries from the recent changes page in a future release. Hope that helps! -- Ryan 16-Jun-2007 13:56 PDT
Thanks Ryan that was very useful. Although it still doesn't change the fundamental need to allow admins to effectively block right access comtpletely, to un autherised users. Fine grained controls would be great. But in the mean time a simple global check box would be great. The opention to stop non admin users from creating new and editing existing content. Whilist it does fly in the face of the orginal everyone colaberating, wiki ideal I think its nessary to have it as an option.
In terms of deleting, I would suggest having a super delete option avalible to admins to delete any record of the content.
It would be nice not to need these features, but unfortunatly its a fact of life on the net. Keep up the good work Charlie
--Charlie 04-Jul-2007 15:32 BST

Hide the Register Link (on top)[edit]

Moved from the Feedback page:

Is there a way to hide the register link from the top of the wiki so that one can control who can register on a private wiki

At the moment there isn't a configuration setting, but you could manually remove it by editing the /WEB-INF/jsp/user-menu.jsp file and removing any <authz:authorize ifNotGranted="ROLE_EMBEDDED">...</authz:authorize> tags and their content. Several people have asked for a way to disable registration, so some sort of configuration option will almost certainly be added to a future release. -- Ryan 27-Mar-2007 22:09 PST
In our environment (JAMWiki embedded in a portal) I solved this by assigning all users ROLE_EMBEDDED. If I recall correctly this also hides the Login/Logout links (look at user-menu.jsp). A JAMWiki configuration option could be based on the role mechanism, thus allowing configuration from within JAMWiki and from outside (by configuring acegi security). -- Rainer 28-Mar-2007 00:00 PST
Hi Rainer - this is something I've been looking at for a while. At present Acegi configuration is all XML-based, and there doesn't seem to be an obvious way to provide web-based configuration options for security settings. Any suggestions you have for allowing roles or other Acegi settings to be modified via JAMWiki configuration settings would be much appreciated, as thus far I haven't come up with any good options. -- Ryan 28-Mar-2007 06:44 PST
In this case it would not be necessary to change any acegi configuration settings but you would assign different roles to a user. That means the acegi configuration stay the same, but according to a user's role the register link is displayed or it is not. The roles are assigned by an implementation of UserDetailsService when a user logs in. I think JAMWikiDaoImpl could fetch the roles from the JAMWiki database. Probably roles could be changed for a loged user, too, by changing the information provided by SecurityContextHolder.
Do you really want to change acegi settings through the web interface? Those settings are normally only necessary when installing JAMWiki, and I see it as an extra measure of security that you can only change them when you have access to the configuration files and can restart the server.
Anyway, all configuration is parsed by Spring at startup to create Java Beans. The easiest, but somewhat limited, option would be to read configuration parameters from a property file with PropertyPlaceHolderConfigurer. This property file could be created or changed by the JAMWiki admin console (in fact in could be Another option would be to provide your own implementations of certain interfaces to fetch configuration data from JAMWiki database instead the XML file. E.g. you could create your own implementation of AbstractFilterSecurityInterceptor reading the URL <-> Role mapping from the database instead of FilterSecurityInterceptor being configured in the XML configuration.
I hope this makes sence to you. I don't have much time to work on JAMWiki, but if you have any questions feel free to ask. I'll try to keep an I at the discussions here. -- Rainer 28-Mar-2007 10:14 PST
Sorry for taking so long to respond. Your comments make sense - I think the particular use-case I was thinking of was allowing an admin to change the roles which could access a page (such as the Special:Translation page), but I guess that could be handled just as easily by having a different role associated with each type of login-protected special page, and then assigning additional roles to users as needed. That would keep the code from becoming too complicated while also using Acegi in a way that it's designed for, rather than trying something unusual. -- Ryan 01-Apr-2007 22:43 PDT
I guess something changed seense 2007 because I don't see any quoted text in the WEB-INF/jsp/user-menu.jsp -- CAB 10-Dec-2011 12:05am EST


I have a question about user/roles permission mechanism. In Special:Manage page an admin have a option to make a page read-only and/or admin-only. When a new role is created is possible assign an permission for an specific page/topic for a user group?

e.g. I have a group of RDBMS_ADMIN in my team and only this group can read/edit pages assigned to RDBMS_ADMIN group, because this pages contents can not be read by all users. --rafaelcba 21-Jul-2008 06:40 PDT

Roles Storage[edit]

Where to retrieve roles can be configured in Acegi Security by providing a customized userDetailsService. The default implementation could use the proposed jamwiki_user_roles table. Other implementations I've used use hard-coded roles for demo systems or retrieve roles from a portal server using a webservice. Of course LDAP would be possible, too.

How about this: Add a role retrival strategy to JAMWikiDaoImpl (strategy pattern). The default strategy accesses jamwiki_user_roles. A strategy accessing LDAP could be delivered, too. The strategy to use will be configured in applicationContext-acegi-security.xml (jamWikiAuthenticationDao bean definition). --Rainer 16-May-2007 01:29 PDT

Thanks, I'll take a look at the docs and hopefully get something together that implements your idea in the next week or so. I've spent a good chunk of the past week getting up to speed on how the various Spring configuration beans interact, and at this point I'm significantly more impressed with the framework - thanks again for all of the work you've done implementing it on JAMWiki. -- Ryan 16-May-2007 23:57 PDT


Will it be possible to restrict access of users/groups to a subset of pages/categories/namespaces? -- klaus

In the long term I expect that the permission system will become more flexible, but initially I expect it will probably be fairly simple, with the ability to restrict broad tasks (such as editing, uploading, creating new pages) to either specific users or pre-defined groups (anonymous users, logged-in users, or admins). My work schedule has been a killer over the past few months so unfortunately I haven't had the time/energy to do as much coding as would be required to implement an advanced permission system for the next release. -- Ryan 18-Jun-2007 21:40 PDT

Status Update[edit]

As of 07-July-2007 I've got all of the code in place for assigning roles to users and groups and storing those roles in the database. The Special:Roles page allows users and groups to be assigned roles. All of this code is in Subversion and on The next step will be to actually use the assigned roles - Acegi is already set up to limit certain pages to certain roles, so it's a simple matter of making sure that WikiUser objects pull their roles from the database.

Some notes about the current implementation:

  • It's not yet well tested, so there are probably some bugs.
  • The Special:Roles UI needs more polish. At the moment it doesn't remember the role or login used in searches, and there isn't enough feedback about the success of assigning roles to users or groups.
  • I need to tie the new code in with the existing caching code to ensure that performance is not affected.
  • The queries used with roles have only been tested on Postgres. It's possible that other databases may need database-specific implementations.
  • For users who use outside systems (CAS or LDAP) for storing roles I'll need to add the ability to disable the new role-retrieval and setting code. That shouldn't be tough to do.
  • The new code is still rough and will probably get some cleanup prior to the final 0.6.0 release.
  • The following options will need to be converted to use roles and then removed:
    • Disable anonymous editing
    • Allow non-admins to move topics
  • Add a check so that the current user cannot remove ROLE_ADMIN from his account. This will hopefully avoid bug reports of the "I've removed ROLE_ADMIN from all users of the wiki, how do I access the admin pages" sort.

Feedback is welcome as always. Hopefully this will get finished soon so that I can begin addressing other issues for a final 0.6.0 release. -- Ryan 07-Jul-2007 21:22 PDT

Any plans or thoughts on integrating with an LDAP directory? Currently we're building an integrated single-signon system, and are trying to avoid each system with its own unique ID. -- Marc
I believe Acegi can be configured to handle this. User:swift built an integration with a CAS system that pulls roles from that system, so it should be possible to configure Acegi to do the same. I don't know if such a structure can be configured through JAMWiki's web-based configuration tools, however, so it may take someone who is using LDAP and willing to commit patches before a tight integration is available. -- Ryan 15-Jul-2007 09:55 PDT

Current Status[edit]

As of 15-July-2007 the code to use roles from the database (or from another source) is in place. It's buggy, and there is more to do, but it's generally usable / testable. Some currently known issues:

  • The existing is_admin field in jam_wiki_user needs to be removed and those users need to be given ROLE_ADMIN. Code committed to trunk on 22-July.
  • I may have broken Rainer's CAS setup with these changes, so verification on that front would be appreciated. Update: I can't test this, but I think the CAS setup should still be OK.
  • I need to tie the new code in with the existing caching code to ensure that performance is not affected.
  • The queries used with roles have only been tested on Postgres. It's possible that other databases may need database-specific implementations. UPDATE: HSQL works fine.
  • For users who use outside systems (CAS or LDAP) for storing roles I'll need to add the ability to disable the new role-retrieval and setting code. That shouldn't be tough to do.
  • The following options will need to be converted to use roles and then removed:
    • Disable anonymous editing Code committed to trunk on 28-July.
    • Allow non-admins to move topics Code committed to trunk on 22-July.
  • Add a check so that the current user cannot remove ROLE_SYSADMIN from his account. This will hopefully avoid bug reports of the "I've removed ROLE_SYSADMIN from all users of the wiki, how do I access the admin pages" sort. Done as of revision 1777.
  • More default roles are needed to allow administrators finer-grained control over their systems. For example ROLE_LOGIN could be used to prevent access to the login screen for setups that authenticate in other ways.
  • If a "remember me" cookie is set and the system is upgraded → badness & evil. Fixed. However, the system may be only partially logged-in after the upgrade, and more testing is needed to make sure other problems haven't been introduced. Update: I think this is fine as of 29-July-2007.
  • After registering the user is not logged in. Probably due to revision revision 1582. Fixed as of 04-August-2007.
  • When user or group roles are changed for logged-in users using the Special:Roles interface, the user's permissions are not updated until their credentials expire.
  • If a user has ROLE_TRANSLATE but not ROLE_ADMIN they still need a link to Special:Translation in the user menu or elsewhere. Done as of 04-August-2007.
  • ROLE_ADMIN needs to be split into ROLE_ADMIN and ROLE_SYSADMIN. The latter will have access to the Special:Admin pages, and the former will be able to delete topics and perform typical wiki-admin duties. Done as of 05-August-2007.

This list isn't complete, but it gives an idea of where things are, and I'll update it as work gets done. -- Ryan 15-Jul-2007 09:55 PDT

Status updated on 22-July. I'll be working on this a bit more today, so hopefully soon the code will be ready for a beta release. -- Ryan 22-Jul-2007 10:51 PDT
As of 29-July-2007 the major issues seem to be resolved. I'll continue to run this locally for a bit, and after a bit more testing I'll push the latest code to Provided there are no surprises then it should be time for JAMWiki-0.6.0-beta1 shortly after that. -- Ryan 29-Jul-2007 15:27 PDT
As of 05-August-2007 I've split ROLE_ADMIN into ROLE_ADMIN and ROLE_SYSADMIN. Translators should still be able to access Special:Translation, but will not see Special:Admin - if anyone has any problems please let me know. -- Ryan 05-Aug-2007 19:40 PDT
As of 31-July-2007 the latest code is running on -- Ryan 31-Jul-2007 22:57 PDT