Comments:JAMWiki 0.7.0

[Edit]JAMWiki 0.7.0

Archived from the Feedback page:

[Edit]Current Plans

I'll be heading off on a much-needed vacation starting this weekend and lasting until mid-July, so development on the next version of JAMWiki probably won't start in earnest until I return. While I'm gone I'll probably be restricting edits on jamwiki.org to registered users to cut down on any spam, although I'll try to check in occasionally to see how things are going - if anyone else notices spam, unanswered user queries or other issues I'd be grateful for any help in resolving things.

The big plan for the next release is upgrading Acegi, hopefully making LDAP integration simpler in the process and adding some flexibility for those who want to add more control over users. In addition, folks at my workplace are grumbling about not being able to set email alerts when topics are changed, so that may be climbing up the priority list. And as always I suspect that a few contributors may show up with great ideas for features or changes of their own to implement. -- Ryan 04-Jun-2008 21:57 PDT

[Edit]Status Update (September 2008)

While a final release of JAMWiki 0.7.0 remains at least a couple of months away, there is a significant amount of work that has already been completed - see the Changelog for the latest updates. The upgrade to Spring Security 2.0 is more-or-less done, although a major piece of work remains in making JAMWiki utilize Spring Security's LDAP and OpenID integrations.

I usually only release the first beta when all database schema updates have been made, and since at this point it's not clear if additional schema changes will be required I'm holding off on a beta. However, if anyone is interested in testing but cannot build from source, please add a comment here and I can put something together. As always, feedback and bug reports are appreciated. -- Ryan 12-Sep-2008 22:35 PDT

[Edit]JAMWiki 0.6.7 Beta 1

In order to get bugfixes out without having to wait longer for 0.7.0 to be finished I've merged all bugfixes from trunk to a 0.6.7 branch. The first beta is available below:

• http://jamwiki.org/jamwiki-0.6.7-beta1.war
• http://jamwiki.org/jamwiki-0.6.7-src.zip

There won't be any new features in this release, but a list of bugfixes and translation updates are available in the CHANGELOG. Feedback is appreciated - barring any surprises I'll make a final release in the next 1-2 weeks. -- Ryan 17-Sep-2008 22:15 PDT

[Edit]JAMWiki 0.6.7 Final

The release notes are done and I've done a quick test of a clean install and an upgrade (both seem fine), so as far as I'm aware JAMWiki 0.6.7 is ready for release. I'll wait until tomorrow to do the final push, so if anyone has a bug report, translation update, or other change that needs to go in speak up now. -- Ryan 27-Sep-2008 15:26 PDT

[Edit]H2 migration failure

Archived from the Feedback page:

I tried to move my wiki from the internal HSQLDB to a H2 (cp. Installation#H2). This worked fine with a fresh JAMWiki installation with no user data. But now that my database (jamwiki.data) has grown for some time it fails with the error message Referential integrity constraint violation: JAM_F_CAT_CHILD_ID: PUBLIC.JAM_CATEGORY FOREIGN KEY(CHILD_TOPIC_ID) REFERENCES PUBLIC.JAM_TOPIC(TOPIC_ID) [23002-107] (here's the entire jamwiki.log.0,20090204,095631). Looks like a bug in the database migration code, right? --tapaya 04-Feb-2009 02:09 PST

I'll need to update the documentation - migration will only work on an empty JAMWiki database (no users, no setup, etc). Once there is data in a database then migration will fail as it will be trying to do things that are not allowed, such as copying topics that have the same IDs or creating users when users with the same login already exist. Actually, looking at the log you've uploaded it does appear that there is a problem - there is a relationship between topics and versions that is failing. I'll investigate. -- Ryan • (comments) • 04-Feb-2009 07:39 PST

I am unfortunately not going to have much time to devote to JAMWiki this weekend - is it critical that you complete a migration soon, or can it wait a while? Currently the migration option is labeled "experimental" because it was contributed by another developer and I have not researched it closely or built any unit tests for it. My plan was to re-visit this functionality during the JAMWiki 0.8.x cycle, but I'm more than happy to look into it more closely in the coming week or two if it will help you out. -- Ryan • (comments) • 05-Feb-2009 20:41 PST

It would be really nice to migrate to H2 asap, because I'm evaluating things here. However, as a workaround I could seek for a way to run 2 separate instances of JAMWiki concurrently (maybe 2 Tomcat instances?). Any thoughts? --tapaya 06-Feb-2009 04:55 PST

The issue appears to be the order in which tables are created during migration in JAMWiki 0.6.7 - the code is trying to populate the category table before the topic table is populated. I've already fixed this for 0.7.0 but am doing additional testing now to verify that there aren't any other issues. As a result, this isn't something that can be fixed without waiting for the new release. However, running two instances of JAMWiki concurrently (your second option above) is very easy - simply set up two separate applications on your Tomcat server. For example, on this server I run both jamwiki.org and a personal server. jamwiki.org is deployed under /wiki/ while my personal version is deployed as a separate application. Hopefully this solution will work for you. Thanks again for the testing and bug reports. -- Ryan • (comments) • 08-Feb-2009 19:54 PST

Now that was easy: I basically unpacked the jamwiki WAR file in tomcat's webapps folder a second time and named it differently ("wiki") ... and there's my second JAMWiki instance! I just put a link in there to the old (HSQLDB based) instance and made the old wiki read-only (i.e. changed role permissions) and I'm all set. Of course, this is only a workaround (migrating the old stuff would still be more elegant and comfortable) but it works ... Thanks a lot, Ryan! --tapaya 09-Feb-2009 02:32 PST

revision 2468 should resolve the remaining migration issues - with these changes I'm now able to successfully migrate the full jamwiki.org history to H2; before these updates I was getting various database and out of memory errors. The fixes will be included in JAMWiki 0.7.0. -- Ryan • (comments) • 09-Feb-2009 21:53 PST

[Edit]Page based permissions

Archived from the Feedback page:

I can't find any easy way to set up permissions per page (jamwiki 0.7.0). I looked at the spring security, i am just trying to get the hang of it, but i think i understand how to set the roles for a page but not really how to allow all users to view all pages, and all users to edit by default, but only allow some users to edit particular pages.

I guess one way would be to set the filter to :

<intercept-url pattern="/**" access="ROLE_VIEW" />
<intercept-url pattern="/**/Special:Edit" access="ROLE_EDIT_EXISTING,ROLE_EDIT_NEW" />
<intercept-url pattern="/**/Special:Edit?topic=SpecialPage1" access="ROLE_SPECIAL_EDIT" />
<intercept-url pattern="/**/Special:Edit?topic=SpecialPage2" access="ROLE_SPECIAL_EDIT" />
<intercept-url pattern="/**/Special:Edit?topic=SpecialPage3" access="ROLE_SPECIAL_EDIT" />

Is this the right way to do it (I am the person above with the user roles problem so i can't test it at the moment (as i can't assign any new roles to users) but is this the right idea or is there a better way to do this? It seems a bit painful if there are a lot of pages - is there a way to group the pages together?

From the "manage" tab you can mark pages as admin-only or read-only, but you're right that finer-grained permissions currently require Spring Security configuration. The order that filters are defined matters, so define the least specific filters ("/**") last. Also, you can use wildcards to simplify things, so instead of the three Edit patterns specified you could do:

<intercept-url pattern="/**/Special:Edit?topic=SpecialPage*" access="ROLE_SPECIAL_EDIT" />

A simpler approach might be to protect within a subdirectory, such as:

<intercept-url pattern="/**/Special:Edit?topic=Special/*" access="ROLE_SPECIAL_EDIT" />

I'm not sure if that fully answers your questions, so let me know, and thanks for the feedback! -- Ryan • (comments) • 25-Feb-2009 22:25 PST

This didn't work, but i guess jamwiki doesn't use the spring security by default. What do i have to do to 'turn on' the spring security system? (sorry i really a newbie to this stuff)

Spring Security is definitely used by default, so you shouldn't have to "turn on" anything. If you'd like you can upload your applicationContext-security.xml file and I can take a look, although please wait until after 7:00 PM Pacific time to do so - one of my co-workers pointed out the fact that there is a bug in the current code that breaks non-image uploads, and I haven't yet pushed the fix to jamwiki.org. -- Ryan • (comments) • 26-Feb-2009 07:10 PST

Have you actually tested that this works. I played around with the applicationContext-security.xml file for a while and found some weird behaviour.

I restored the original file from the jamwiki-war. When I changed the permissions for edit to :

<intercept-url pattern="/**/Special:Edit" access="ROLE_SYSADMIN" />

This worked - I was logged in as rebecca - a user with edit role but not sysadmin, whenever i tried to edit a page i was asked to log in (although i think better behaviour would be to say permission denied considering i was already logged in - but anyway that is less of a big deal). Then i added the * after the Edit to make sure that the wild character was working. like this:

<intercept-url pattern="/**/Special:Edit*" access="ROLE_SYSADMIN" />

Same behaviour as above. Then I added the question mark like this :

<intercept-url pattern="/**/Special:Edit?*" access="ROLE_SYSADMIN" />

And it no longer worked - i was not asked to log in and was allowed to edit.

So is it possible the question mark is causing problems - is it a special character? Do i need to somehow escape the question mark? I tried the standard backslash escape ("/**/Special:Edit\?*") but that didn't work.

Update - I have been looking around and found that in the http element adding path-type="regex" (it uses ant by default) should support more flexible pattern matching in the intercept-url, but when i set the path type to regex, i get an exception in catalina.out and the app doesn't load. Will investiage further and put up any answers i find.

Looks like you're right - Spring Security won't match against query parameters using ANT pattern matching, so you have to change the ANT patterns to regular expressions. The following works for me:

	<http auto-config="false" entry-point-ref="authenticationEntryPoint" path-type="regex">
		<intercept-url pattern="/(.)+/Special\:Edit(.)+StartingPoints" access="ROLE_NEW_ROLE" />
		<intercept-url pattern="/(.)+/Special\:Admin" access="ROLE_SYSADMIN" />
		<intercept-url pattern="/(.)+/Special\:Edit" access="ROLE_EDIT_EXISTING,ROLE_EDIT_NEW" />
		...
	</http>

When I run this locally it isn't redirecting me to the login page on error - instead I get sent to a generic 403 error page - so that's something that needs to be fixed, but otherwise I think it's working as expected. Thanks for your patience! -- Ryan • (comments) • 26-Feb-2009 18:56 PST

Great, got it working now. Thanks for your help. I'll look into the sign sign on stuff now.

A quick note - while investigating the above issues it turns out that for non-logged-in users the system properly redirects to the login page when access is denied. For loggged-in users a generic 403 error is thrown, so I need to add some sort of handling for that. I need a bit of sleep first, but will investigate shortly. -- Ryan • (comments) • 26-Feb-2009 19:31 PST

Update - the access denied issue should be fixed by revision 2482. I need to test this on an app server other than Tomcat, and provided all is well I'll then push out JAMWiki 0.7.0. -- Ryan • (comments) • 28-Feb-2009 00:21 PST