Description
Acegi is currently on milestone two in the buildup to their next major release. The new release will offer a significant number of improvements, including better LDAP support, easier configuration, and tighter Spring integration. This upgrade is also a chance for much of the legacy LDAP and authentication code in JAMWiki to be fully converted to use Acegi, thus offering more flexibility to users.
UPDATE: Acegi (now Spring Security) version 2.0 has been released. Upgrading to the new version will be the major focus of the 0.7.0 release.
Author(s)
Status
Until Acegi is closer to a final release it probably doesn't even make much sense to start this work. That said, cleanups to modify existing JAMWiki code to make better/cleaner use of the current Acegi infrastructure would be welcome.
The actual conversion to the new Acegi functionality will be a significant opportunity to improve JAMWiki and will almost certainly warrant a major bump in the JAMWiki version number (example: 0.7.x → 0.8.0).
Comments
I didn't take a closer look to the changes in Acegi 2.0 up to now, but I think, for a better integration into JAMWiki, a big change would be necessary: jam_recent_change and jam_watchlist should take an username instead of of the wiki_user_id, without foreign-key constraints to jam_wiki_user. Also, the interface QueryHandler should take usernames instead userids for changes on watchlist. --hp 14-Apr-2008 00:14 PDT
- I think you're right that it will be necessary to switch from using user ID to login in many places. Writing and testing the upgrade scripts for that is gonna be ugly, but in the end it should be a worthwhile change. -- Ryan 14-Apr-2008 08:13 PDT
Update June 2008
JAMWiki 0.6.6 is out, and I'm planning on beginning work on the Acegi upgrade next, with the goal of making that one of the key features for 0.7.0. I'll be on vacation through mid-July, but once I return I'd like to start work. As part of this integration I think it makes sense to begin using user logins (instead of ID) as primary keys to make LDAP integration easier (as suggested above by Hans), and as a result there will be some pain as the database schema will have to change. It should be possible to automate everything so that the upgrade remains painless for users, but if not then this approach may need to be re-visited. -- Ryan 04-Jun-2008 22:15 PDT