jamwiki.org is recovering from a hardware failure that required obtaining a replacement server. The Jira bug tracker is currently unavailable but should hopefully be restored in the next 3-10 days.

Comments:Configuration

Contents

[Edit]Virtual Wikis

How do I change the Default Virtual Wiki http://www.myserver.com/jamwiki/ from mapping en to e.g. de??

Testing working of commetnt...

[Edit]Remove Virtual Wikis

How do I remove obsolete virtual wikis? I created one just to test how does it work, and I want to remove it. --MatuDuke 19-Jun-2008 06:54 PDT

At the moment there isn't a user-friendly way to remove a virtual wiki. You can try deleting the record from your jam_virtual_wiki table, although there will be some dependencies on other tables that would also need to be removed. As long as you remove any record of the virtual wiki from your web.xml file there should be no harm in keeping an unused virtual wiki around. -- Ryan 19-Jun-2008 10:33 PDT

[Edit]How can i change the background of the stylesheet?

Copied from the FAQ page:

Because i'm changing the image of the background in the style sheet and when i save the changes the wiki doesn´t change into my new background.

That should work, provided the CSS is correct. You may also need to do a SHIFT+reload in your browser to ensure that your browser isn't displaying a cached version of your CSS file. Let me know if you encounter further problems. -- Ryan 12-Dec-2006 08:28 PST

[Edit]adding navigation entry

Archived from the Feedback page:

Hi Ryan, when I add - as administrator - a navigation-link everything works fine. The new link - to a non-existing page - is marked red. When I click the link and add some words to the new page and save the content, the new red link still remains red! I tried to reload the page [str]+R and all the stuff - with the browser but the link remains red. That means it still opens the editing mode for the page. ;-) --Michael Habbert 18-Feb-2007 02:24 PST

I'm not sure that will necessarily be easy to fix - at the moment the left nav, stylesheet, footer, etc. are cached, and it's only when that page is modified or the cache expires that the cache is refreshed. In this case, JAMWiki doesn't know that anything in the left nav changed, so the cache never clears. You can clear it automatically from the Special:Admin page by clicking the clear cache link, which should update the link color. I'll give some thought to how this might be fixed, but doing so might be a trade-off for performance, so I suspect the best solution for now is simply to clear the cache when needed. -- Ryan 18-Feb-2007 10:25 PST
I just tried this and discovered that there isn't an option on the admin page to clear the cache. Oops. A workaround until I build one is to simply edit the LeftMenu to add some minor change and re-save, and that will update it. -- Ryan 18-Feb-2007 10:49 PST

[Edit]Is there a way to use classic mediawiki search instead of lucene?

Archived from the Feedback page:

Hi everybody, in admistration tools there is a possibility to choose Search Engine, but Lucene Search engine is the only option. I would like to use classic search, for its organization of search results. and is there a way to change default action for search field to 'Go to' instead of 'Search'? So that the user could be redirected directly to the page if it exits? Thank you for your time. regards Matus Majchrak

At the moment there isn't a configuration option for using "Go To" as the default, but if enough people ask for that feature then it would be easy to implement. If it something that you really want you could implement it locally fairly easily - in your wiki installation you can edit the file /WEB-INF/jsp/wiki.jsp and change the following lines from:

	<input type="submit" name="search" value='<f:message key="generalmenu.search"/>'/>
	<input type="submit" name="jumpto" value='<f:message key="generalmenu.jumpto"/>'/>
to:

	<input type="submit" name="jumpto" value='<f:message key="generalmenu.jumpto"/>'/>
	<input type="submit" name="search" value='<f:message key="generalmenu.search"/>'/>
Hope that helps! -- Ryan 22-Feb-2008 07:24 PST
Thank you Ryan

[Edit]Images

Archived from the Feedback page:

Please reply to this question if any body knows:

My question is I want to add one link in the Jamwiki left menu, when i click that It should open another webpage, and when ever I upload a file , it should create a link in that webpage, so that i can access from my page itself..

regards, M.Seetharam Reddy, e-mail:seetharam.maila@cmcltd.com

      msr.reddymail@gmail.com
Unfortunately the Mediawiki syntax (which JAMWiki uses) doesn't allow <img> tags, so images must be added by using the Special:Upload functionality. See metawikipedia:Help:HTML in wikitext for details of what HTML is allowed, and metawikipedia:Help:Images and other uploaded files for details on using images in a wiki. -- Ryan 05-Feb-2008 20:13 PST

[Edit]Remove Image

Is there a way to remove an image? Bob White 26-May-2009 17:33 PDT

Admins can delete images and topics via the "Manage" tab at the top of the image/topic page. -- Ryan • (comments) • 26-May-2009 19:14 PDT

[Edit]CSS Question

Archived from the Feedback page:

  • Hi guys. I found JAMWiki today, found it very easy to setup and use, as it is VERY similar to MediaWiki. My question is: where can I find a CSS file with classes definition like tables and so. For instance, I was looking for the very nice table class "wikitable" aka "prettytable" that is used on most WikiMedia wikis. I could not find it, nor any CSS file to add that class. --Zajoman 11-May-2007 04:17 PDT
  • Yo, I'm sorry to have probably bothered you with such a stupid question. I should have taken a much longer look at the StartingPoints page. --213.215.115.34 11-May-2007 06:22 PDT
No such thing as a stupid question :) The documentation for JAMWiki is TERRIBLE, and needs improvement. If anyone is interested in starting to reorganize / create documentation I would help out as much as time allows. I would imagine such a reorg could probably follow the structure from http://www.mediawiki.org/wiki/MediaWiki, with three main sections: user documentation, administrator documentation, and developer documentation. The existing Installation doc would fall under "administrator" (and should be moved to Help:Installation), a new Help:Configuration doc could be created, things like the existing Wiki Syntax doc would fall under "user". Category:JAMWiki contains most of the existing docs now and might be a good place to start.
As a side note, if anyone is interested in helping out with documentation please comment about your plans here before starting a reorg of the site's docs, just to make sure we're all on the same page :) -- Ryan 11-May-2007 08:13 PDT
Note that I've taken a stab at re-organizing the documentation - see Category:User Documentation, Category:Developer Documentation and Category:Administrator Documentation. -- Ryan 10-Jun-2007 20:18 PDT

[Edit]Time format (again...)

Archived from the Feedback page:

After trying to resolve the problem by extensive trial-and-error and bombarding people and forums I'll epitomize it here again. I want to get rid of the timezone within signatures, i.e. "18:05 +01:00" should display as "19:05". The server environment:

  • SuSE Linux 9.2
  • TZ is set to CEST
  • TZ for tomcat5 in wrapper.conf set by wrapper.java.additional.9=-Duser.timezone=CEST

date behaves well and displays "19:05", while the JAMWiki displays "18:05" (+01:00). Any suggestions? --Frank 26-Oct-2007 03:48 PDT

Signature patterns are configured using the "Pattern for dates in signatures" setting from Special:Admin. To remove the timezone I believe all you should need to do is remove the "zzz" from the end of the pattern. Let me know if that resolves your issue or if there is another problem. -- Ryan 26-Oct-2007 19:20 PDT
Hi, Ryan, alas it does not. Removing the timezone code I don't get "19:05" but "18:05" regarding the example above. -- Frank 02-Nov-2007 05:29 PST

Since DST reset on last weekend of October (Germany) signature expansion gives wrong times. 13:00 real time is shown as "13:00 +01:00". Which one is the culprit, the OS (Linux), the app server (tomcat) or JAMWiki? --Frank 26-Nov-2007 09:00 PST

JAMWiki simply passes the signature pattern configured in Special:Admin to java.text.SimpleDateFormat, so the problem is likely either at the OS level or the app server. I think the app server is set up to use the OS time settings by default, so you may want to first verify that the OS time is correct and then make sure that the app server isn't using custom settings. When I get home tonight I'll try to remember to check the JAMWiki code to make absolutely sure that nothing strange is happening, although time settings on jamwiki.org seem to have survived the end of daylight savings so I think it's OK. -- Ryan 26-Nov-2007 10:01 PST
Sorry, a long time since... A command line date provides correct times (CET). I've been fiddling around with wrapper.conf timezone parameter wrapper.java.additional.9=-Duser.timezone=Europe/Berlin (commenting out or setting timezone to CET and CEST), but displayed times in JAMWiki stay untouched... I am at my wits' end. --[[[User:frareinif|Frank]] 05-Dec-2007 04:07 PST

[Edit]DATASOURCE_README.txt

Archived from the Feedback page:

The DATASOURCE_README.txt file has been in Subversion since the days before JAMWiki forked from Very Quick Wiki. I didn't delete it because I don't use data sources and wasn't sure if the information is valid or not. Can anyone confirm whether the configuration for data sources outlined in that file is accurate? If so then the information should be added to Configuration#Persistence settings and Installation#Database Configuration, and if not the file should probably be deleted. -- Ryan 22-Jul-2007 10:58 PDT

[Edit]Rename default virtual wiki

Is it possible to change the name of the default virtual wiki? --hp 18-Nov-2008 00:23 PST

See Feature_Requests#Rename_Default_Virtual_Wiki. -- Ryan 18-Nov-2008 07:53 PST

[Edit]Using permissions to hide pages

Archived from the Feedback page:

Our department wants to put non-public data into JW which can only be viewed by members of our department. It is not plain to me whether it's possible to define rolls to fit to this. -- Frank 14-Sep-2007 04:26 PDT

Currently that level of granularity is not available. If it's absolutely a requirement for you then it might be achievable by creating a new role for the department (ROLE_DEPARTMENT_FOO), assigning that role to department members, and then requiring that all hidden topics for that department use a specific prefix, such as "DepartmentFoo/Topic". You would then need to manually modify the /WEB-INF/applicationContext-acegi-security.xml file to add the following lines to the "filterInvocationInterceptor" section such as:

<value>
    PATTERN_TYPE_APACHE_ANT
    /**/Special:Admin=ROLE_SYSADMIN
    /**/Special:Edit=ROLE_EDIT_EXISTING,ROLE_EDIT_NEW
    /**/Special:Login=ROLE_ANONYMOUS,ROLE_USER
    /**/Special:Maintenance=ROLE_SYSADMIN
    /**/Special:Manage=ROLE_ADMIN
    /**/Special:Move=ROLE_MOVE
    /**/Special:RecentChangesFeed=ROLE_ANONYMOUS,ROLE_USER
    /**/Special:Roles=ROLE_SYSADMIN
    /**/Special:Setup=ROLE_ANONYMOUS,ROLE_USER
    /**/Special:Translation=ROLE_TRANSLATE
    /**/Special:Upload=ROLE_UPLOAD
    /**/Special:Upgrade=ROLE_ANONYMOUS,ROLE_USER
    /**/DepartmentFoo/**=ROLE_DEPARTMENT_FOO
    /**/Special:*DepartmentFoo/**=ROLE_DEPARTMENT_FOO
    /**/*.jsp=ROLE_ANONYMOUS,ROLE_USER
    /**=ROLE_VIEW
</value>
Note that any changes to this file will require a server restart before they are active. This approach is definitely a hack, I haven't tested it so it may have issues, and there will probably still be ways for a motivated individual to work around it, but if it's a requirement for your company then this might be a decent temporary solution until that functionality is eventually available in JAMWiki (and note that it's not imminent, but will probably be added at some point by someone). Hope that helps. -- Ryan 14-Sep-2007 06:19 PDT
One additional note, upgrades can't support customizations and will overwrite the /WEB-INF/applicationContext-acegi-security.xml file, so if you take this approach you will also need to remember to re-add your customizations after any upgrade. -- Ryan 14-Sep-2007 06:22 PDT
Thank you....... testing at last....it works! I'm confident that this will expedite JWs acceptance in our company. -- Frank 21-Sep-2007 02:48 PDT

Hi!

I post a question on Tech:User_Permissions#Hide_the_Register_Link_(on_top) for the same situation described by Frank. This workaround work for me too.

Thanks for this tips!!! --Rafael Torres 21-Jul-2008 07:09 PDT

[Edit]LDAP Setup

Archived from the Feedback page:

I would love to use my LDAP server to authenticate my JAMWiki users - but I was unable to find something like a howto/sample configuration/etc.? Did I miss anything? More precisely my current questions are:

  • What do I use as "LDAP Factory-Class"? Do I have to provide this class or is there any already included?

(The other LDAP options on the admin page are pretty much straight forward.)

  • How (if) does the role-management with LDAP work? Do I have to provide special attributes? Put the users into special groups?

Thanks! -- Andy 03-Nov-2007 00:26 CET

The LDAP code is unfortunately incomplete and not particularly well-tested; when it was put in place it allowed a user's password and login to be verified against an LDAP server, but LDAP roles were never integrated. With respect to the LDAP factory class, LDAP implementations generally provide a JAR file that contains a factory class used for creating LDAP connection - that's the class to specify.
Any feedback you have about the current state of the LDAP implementation and what is missing or needs improvement would be appreciated - integrating with Acegi's LDAP support is on the to-do list, but since it hasn't been a heavily requested feature no one has gotten around to implementing it yet. -- Ryan 04-Nov-2007 08:05 PST
Thanks Ryan - that is somehow the situation I derived from reading the infos in the wiki. Is anybody out there really using LDAP with JAMWiki? Or am I completely on my own? I would appreciate some more details on how to use it, which LDAP implementation(s) have been used successfully and where to start integrating Acegis. Thanks. -- Andy 04-Nov-2007 18:50 CET
I can't honestly say I recall seeing any success reports with LDAP, although generally people only report problems. The biggest issue with the LDAP code is that it was started at the same time the Acegi integration was being done, and in the future the preferred method for handling LDAP would be through Acegi so no further work has been done. If you're saying it doesn't work I can hide it in the next release, and hopefully revisit it in the future. Sorry for the confusion, and thanks for the feedback! -- Ryan 08-Nov-2007 07:15 PST
Since LDAP is a current discussion issue I looked through the latest Acegi code in Subversion, and it looks like LDAP and tighter integration with Spring are major focuses of development for them, so when they release version 2.0 it will be a good time to revisit JAMWiki's security model and work on things like better LDAP integration. In the mean time I think JAMWiki may need to continue along with a somewhat incomplete LDAP integration, although it apparently IS functional given the comments below. -- Ryan 08-Nov-2007 21:21 PST

I've been looking through the code. As an intermediate solutions I would suggest something similar to this:

  • Extend the UserHandler to also retrieve roles for the user (e. g. lookupWikiUser(userName)).
  • Make the UserDetailsService (JAMWikiDaoImpl, InMemoryDaoWithDefaultRoles) use the UserHandler (instead of the DataHandler).
  • Extend the DatabaseUserHandler+LdapUserHandler to use the DataHandler to implement the extended UserHandler interface.
  • Create an AcegiLdapUserHandler to use Acegis methods to retrieve the data from LDAP. This would probably require a few more configuration properties but could also reuse a few of the LdapUserHandler.

Would such a UserHandler-Implementation still need to create all users in the database (as the InMemoryDaoWithDefaultRoles does)?

What do you think? Did I miss anything? If I find a few hours I could try to provide you with a patch? --Andy 10-Nov-2007 06:34 PST

These suggestions all seem sensible, and the first two look like they would be good ideas from even just an organizational standpoint. I'd like to try to use as much of the Acegi LDAP classes as possible, but it sounds like that's something you've considered. My understanding is that Acegi LDAP is still incomplete and is being further fleshed out for Acegi 2.0, so once that release is done I'd ideally like it to be relatively painless to transition JAMWiki code to allow Acegi to handle all of the authentication and authorization details.
The biggest issue, which you've pointed out, is that there needs to be a way to tie edits to users in the JAMWiki database, which is why user accounts were split into jam_wiki_user and jam_wiki_user_info in the first place. I suspect there will be some pain in making sure that a wiki user object exists for all authenticated users, but would need to spend some time looking at code to figure out exactly what's needed.
I'll have more time tomorrow to work on writing code, so I'll hopefully be able to look more closely at your proposal then. That said, I don't have an LDAP server that I use regularly, so it sounds like you have a better grasp of the issues and have looked into this issue. If the changes above work for you and can be implemented in a way that doesn't break existing implementations then I'd say give it a try - if you have a Sourceforge ID let me know what it is and I can give you Subversion access so that you can create your own branch and test things out. -- Ryan 10-Nov-2007 12:40 PST

Hello Ryan,

I'm looking into how to get LDAP working on our Jamwiki installation but am unsuccessfull. Taking into account the date of the last post in this issue, I'm wondering, is there any change/progress on this item? Just commenting out the standard authentication and activating the LDAP authentication doesn't work for me, although credentials are correct and used on various servers in our network. Do I need to install additional things for the Spring Security to work or is it completely integrated in Jamwiki? Kind regards, Eric 22-06-09

JAMWiki 0.7.0 completely overhauled the login and authentication code, so have a look at Configuration#LDAP / CAS / OpenID for some basic information about configuring LDAP, as well as links to the Spring Security reference guide. I don't personally use LDAP, but during 0.7.0 development I did a fair amount of testing with LDAP, and since then a number of users have reported that it works for them. -- Ryan • (comments) • 22-Jun-2009 07:20 PDT

[Edit]User Defined Roles

Archived from the Feedback page:

I installed JAMWiki 0.6.3 and was impressed with ease of installation and configuration. Up and running in five minutes.

I work with a number of developers and we are using a few different Wikis to track code snippets and as a knowledge base for support of our systems. I noticed the ability to create user defined roles and I was interested in using roles to provide a private area for a select group. We keep password information for our systems that we want to share with a few developers. So I need the capability to limit viewing to the users with a specific role. Similar to the Admin functionality and is already built into JAMWiki. I could easily set up a user defined role and assign it to users but I could not find documentation on how the role is then used against a specific page. If this type of functionality available or is this still under development? If you can point me to any additional documentation I would appreciate it.

Thanks for a great Wiki. --Tom 28-Feb-2008 08:35 PST

Thanks for the kind words - it's definitely nice to get some positive feedback in the midst of the bug reports and rants that are more common :) Regarding creating pages that are limited to a select group, unfortunately there isn't much documentation on that yet, but you could do something like the following:
  1. Create a role such as "ROLE_RESTRICTED".
  2. Assign your developers to this role.
  3. Modify the /WEB-INF/applicationContext-acegi-security.xml file and modify the "filterInvocationInterceptor" bean section to restrict a certain path to users with ROLE_RESTRICTED:

		<property name="objectDefinitionSource">
			<value>
				PATTERN_TYPE_APACHE_ANT
				/**/Special:Admin=ROLE_SYSADMIN
				/**/Special:Edit=ROLE_EDIT_EXISTING,ROLE_EDIT_NEW
				/**/Special:Login=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Maintenance=ROLE_SYSADMIN
				/**/Special:Manage=ROLE_ADMIN
				/**/Special:Move=ROLE_MOVE
				/**/Special:RecentChangesFeed=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Roles=ROLE_SYSADMIN
				/**/Special:Setup=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Translation=ROLE_TRANSLATE
				/**/Special:Upload=ROLE_UPLOAD
				/**/Special:Upgrade=ROLE_ANONYMOUS,ROLE_USER
				/**/*.jsp=ROLE_ANONYMOUS,ROLE_USER
				/**/*.css=ROLE_ANONYMOUS,ROLE_USER
				/images/**=ROLE_ANONYMOUS,ROLE_USER
				/upload/**=ROLE_ANONYMOUS,ROLE_USER
				/**/Restricted/**=ROLE_RESTRICTED
				/**=ROLE_VIEW
			</value>
		</property>
You would then need to restart your app server, but that should force a login with ROLE_RESTRICTED for any user trying to access a page such as /wiki/en/Restricted/List_of_Passwords. One caveat is that you will need to remember to update this file again any time you upgrade as it will be overwritten by the upgrade process - hopefully in the future this can be made more "out of the box" so that users won't have to change internal files. If you need further customization you can take a look at the Acegi project's documentation for some guidelines of how to configure their security files. Please let me know if you encounter any issues or have any questions. -- Ryan 28-Feb-2008 10:24 PST

Ryan, thanks for the information on roles. Works great and provided exactly the functionality I was looking for. --Tom 02-Mar-2008 13:48 PST

[Edit]MySQL Timestamp error

Archived from the Feedback page:

Issue with a new install after saving my database configuration (MySQL 4.1.22). I'm on Tomcat 6.0.16, JDK 1.6.04 and JAMWiki 0.6.3. The error I get is:


java.lang.Exception: Failure while executing CREATE TABLE jam_wiki_user 
( wiki_user_id INTEGER NOT NULL, 
  login VARCHAR(100) NOT NULL, 
  display_name VARCHAR(100), 
  create_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, 
  last_login_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, 
  create_ip_address VARCHAR(39) NOT NULL, 
  last_login_ip_address VARCHAR(39) NOT NULL, 
  remember_key VARCHAR(100) NOT NULL, 
  default_locale VARCHAR(8), 
  CONSTRAINT jam_p_wuser PRIMARY KEY (wiki_user_id) )

...

Caused by: java.sql.SQLException: Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause

Anyone seen this?

This mysql page http://dev.mysql.com/doc/refman/4.1/en/timestamp.html might help.

-Doug Donohoe (doug (at) donohoe (dot) info

Thanks for the detailed report. The MySQL scripts actually only use one CURRENT_TIMESTAMP for that table, so it looks like you may have accidentally selected the wrong "database type" setting. Alternatively, if the database type that was selected is definited MySQL there could possibly be another issue, although MySQL setup has been fairly reliable for most users. -- Ryan 23-Feb-2008 13:13 PST


Whoops. I overlooked the database type drop-down list. That fixed the problem. Perhaps in the future the configuration step can try and auto detect based on the JDBC driver. Thanks for the hint.
That seems to be a fairly common mistake, so it's definitely worth considering some ways to simplify. Unfortunately development time is not in plentiful supply, and changes to the setup process require a ton of testing, so it may be a while before that gets revisited, but I'll keep this suggestion around. -- Ryan 24-Feb-2008 08:39 PST

[Edit]Admin Add/Create User

Archived from the Feedback page:

Hi there! We are hoping to use JAMWiki in a 'closed' Wiki scenario (I know it's kind of against the spirit of the application!). I have removed all permissions from the anonymous user, which appears to stop all unauthorised access to the wiki, but there doesn't appear to be a way for the admin user to create legitimate accounts for users. Any help gratefully received.

At the moment there isn't any way to register another person. What you might be able to do is to remove permission checks for the Special:Account page and let people register themselves - to do so you could modify /WEB-INF/applicationContext-acegi-security.xml and update the "filterInvocationInterceptor" to look like the following:

	<bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
		<property name="authenticationManager">
			<ref local="authenticationManager" />
		</property>
		<property name="accessDecisionManager">
			<ref local="accessDecisionManager" />
		</property>
		<property name="objectDefinitionSource">
			<value>
				PATTERN_TYPE_APACHE_ANT
				/**/Special:Admin=ROLE_SYSADMIN
				/**/Special:Edit=ROLE_EDIT_EXISTING,ROLE_EDIT_NEW
				/**/Special:Login=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Maintenance=ROLE_SYSADMIN
				/**/Special:Manage=ROLE_ADMIN
				/**/Special:Move=ROLE_MOVE
				/**/Special:RecentChangesFeed=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Roles=ROLE_SYSADMIN
				/**/Special:Setup=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Translation=ROLE_TRANSLATE
				/**/Special:Upload=ROLE_UPLOAD
				/**/Special:Upgrade=ROLE_ANONYMOUS,ROLE_USER
				/**/*.jsp=ROLE_ANONYMOUS,ROLE_USER
				/**/*.css=ROLE_ANONYMOUS,ROLE_USER
				/images/**=ROLE_ANONYMOUS,ROLE_USER
				/upload/**=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Account=ROLE_ANONYMOUS,ROLE_USER
				/**=ROLE_VIEW
			</value>
		</property>
	</bean>
An admin user could then add specific permissions to that account. Alternatively, if there is some way that JAMWiki could be updated to accommodate your use case feel free to propose a solution, and if time permits and it's not too difficult to implement it could be included in an upcoming release. -- Ryan 29-Jan-2008 12:38 PST

[Edit]How Can I Reset the Administrative Password?

Archived from the Feedback page:

I set up jamwiki late one night a couple of weeks ago. Now I'm ready to spend a little more time configuring it, but I can't remember the administrative password. I've tried everything I can think of, but no luck. Is there anything I can do to reset the password other than starting over with a new installation?

If you've forgotten your admin password then the only way to re-gain access to the wiki is to set up a new version. Sorry! JAMWiki 0.6.6 will include the ability for an admin to reset a user's password, but without the admin password you'll be locked out of all admin functionality. -- Ryan 09-May-2008 22:16 PDT

JAMWiki stores user passwords in the database (in the jam_wiki_user and jam_wiki_user_info tables), so if you have access to the database you can see and edit the encrypted passwords. I used this to reset the admin password to the know password of a non-admin user using the following sql:

update jam_wiki_user_info set encoded_password = (select encoded_password from jam_wiki_user_info where login = 'user-id-with-known-password') where wiki_user_id = 1;
update jam_wiki_user set remember_key = (select remember_key from jam_wiki_user where login = 'user-id-with-known-password') where wiki_user_id = 1;
commit;

If you're using the HSQL database it may be necessary to shut down the appserver first (to get exclusive access to the database files).

Thanks, I used that approach when resetting user passwords prior to the "reset password" feature being added in 0.6.6, so it should also solve the problem for forgotten admin passwords. -- Ryan 20-Jul-2008 20:35 PDT

Was there a default password? Is there any chance I may not have changed it, or did I have to enter a password at some point?

If I need to start over, what's the least I need to do? It appears that the only change that's taken place to the files in the jamwiki webapp folder is that /jamwiki/WEB-INF/classes/jamwiki.properties has been created. Everything else has a modification date of 3/16 or older. Can I just delete that file and restart Tomcat?

How much of the database do I need to get rid of to make it think it hasn't been set up yet? Tables or just the data?

Thanks!

There isn't a default password - that's something you would have been asked for at setup. To set up a fresh install that re-uses an existing database you can try shutting down your app server, deleting your jamwiki.properties file, and then starting up again. You'll get the setup screen, and if you enter the same database settings as before JAMWiki will detect that there is a database already installed and give you a warning message that a database was found, so no new database will be setup. If you click OK that should (hopefully) solve the problem, although I've never tried this using a different admin account / password, so that might be a problem. Hope that works! -- Ryan 10-May-2008 08:08 PDT

Thanks again, Ryan. I had already dropped all the tables before I read this, since I didn't have any data there yet, so I can't tell you if it works to just delete jamwiki.properties. I thought I'd at least have to delete the admin identity from the user and user_info tables, but maybe not. Anyway, I've got it up and running again.

In case you're interested, I'm running it in Tomcat 6.0.14 with PostgreSQL 8.3.1 on Mac OS X 10.4.11.

[Edit]Removing the self registration

Archived from the Feedback page:

It would be better if jamwiki provides a support for approval on registration. so that we can control the unknown users editing the content(in our case our corporate knowledge base).

For time being could you please help me on removing the link "register" on top right corner in wiki pages. --Durga 28-May-2008 11:50 PDT

The easiest way to prevent self-registration is probably to add a permission for the Special:Account page to your /WEB-INF/applicationContext-acegi-security.xml. This will prevent any non-logged in users from accessing the registration page:
	<bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
		<property name="authenticationManager" ref="authenticationManager" />
		<property name="accessDecisionManager" ref="accessDecisionManager" />
		<property name="objectDefinitionSource">
			<value><![CDATA[
				PATTERN_TYPE_APACHE_ANT
				/**/Special:Admin=ROLE_SYSADMIN
				/**/Special:Edit=ROLE_EDIT_EXISTING,ROLE_EDIT_NEW
				/**/Special:Login=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Maintenance=ROLE_SYSADMIN
				/**/Special:Manage=ROLE_ADMIN
				/**/Special:Move=ROLE_MOVE
				/**/Special:RecentChangesFeed=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Roles=ROLE_SYSADMIN
				/**/Special:Setup=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Translation=ROLE_TRANSLATE
				/**/Special:Upload=ROLE_UPLOAD
				/**/Special:Upgrade=ROLE_ANONYMOUS,ROLE_USER
				/**/Special:Account=ROLE_USER
				/**/*.jsp=ROLE_ANONYMOUS,ROLE_USER
				/**/*.css=ROLE_ANONYMOUS,ROLE_USER
				/images/**=ROLE_ANONYMOUS,ROLE_USER
				/upload/**=ROLE_ANONYMOUS,ROLE_USER
				/**=ROLE_VIEW
			]]></value>
		</property>
	</bean>
Hope that helps. The next major release of JAMWiki (0.7.0) will include an upgrade to the latest Acegi version, and I would like to improve support for use-cases like yours as part of that development cycle. -- Ryan 28-May-2008 13:33 PDT
this is not working. since the jamwiki pulling all the info of the current user and not allowing me to add new user when i try to go to Special:Account page in wiki. please tell me where can i remove the register link from wiki, if required i will bookmark and go there whenever required. --Durga 30-May-2008 11:36 PDT
I misunderstood your original question - sorry! At present it isn't possible to register another user. That functionality has been requested by several different users, so it might be something that can be added during the next release cycle. -- Ryan 01-Jun-2008 22:24 PDT
We did this by editing the 'registration.jsp'. Removed the registration form and replaced it by a custom message. There are 3 disadvantages: 1) you have to repeate this step after every jamwiki upgrade 2) to create new users you have to restore the original JSP (this happens not very often here) 3) a jamwiki 'insider' might still fake a webrequest to create a new user --HB 15-Sep-2008 04:46 PDT
Thanks for following up. As part of the 0.7.x release cycle I've got it on my to-do list to investigate whether or not implementing the functionality that you need is feasible - at a minimum I'd like to provide admin options to hide the registration (and a few other) links, and potentially also allow sysadmins to create user accounts. -- Ryan 15-Sep-2008 08:45 PDT

[Edit]Upload folder outside of WAR

Archived from the Feedback page:

I tried to set upload directory to a folder outside WAR. Upload were working fine, downloads were failing. This was obviously because, upload is expected to happen within war. It is fairly easy to keep uploads outside the war by writing a downloadservlet or implementation of JAMWikiServlet which would be responsible to download the files requested. I just implemented this feature to keep uploads outside of war. All I changed is constructing the link for files and images to point it to a download servlet with request parameter as actual file url of the file. It works perfectly for image (inline) and file download. Is there a plan to implement this? Would my implementation be welcomed? BTW, I like JAMWiki after I evaluated JSPWiki and XWiki. I liked its simplicity and code. Way to JAMWiki!!! -- Satish 12-Nov-2008 22:14 EST

Thanks for the kind words. If you have working code available that you are willing to release under the LGPL license then it's definitely something that could be integrated into a future release. Feel free to upload it, and provided the code can be implemented cleanly (ie without requiring changes to too much existing code) then adding it to the next release should be fairly simple. Alternatively, see How to Help for details about getting Subversion access. -- Ryan 12-Nov-2008 20:47 PST
I too think having the upload directory outside of the WAR directory makes much more sense for administration and security reasons. I currently have JAMWiki set up with both the database and upload directories outside of the WAR tree. I have to use Apache HTTPD to serve the upload directory, but it's working ok, for the most part. --Tim 31-Dec-2008 11:50 PST

[Edit]Preventing search

Archived from the Feedback page:

I'm using a role to keep a few pages that are restricted so a number of developers in my group can share passwords on our Wiki. I just realized that the restricted pages are being indexed for searching so if I do a search for a keywork like "password" I often get hits on my restricted pages and each hit provides enough context that the passwords are usually visible in the search page. Is there any functionality provided by the search engine to stop indexing of specific pages or better yet to stop searching based on a role? I've been using JAMWiki for about a year now and I'm really impressed at how solid it is and how easy the upgrades have gone. Thanks. --Tom Schueller 03-Dec-2008 23:31 PST

Thanks again for the kind words - glad the software is working well for you. As to preventing search of certain topics, two disclaimers: first, at present the system currently isn't designed to offer that capability, and second, I haven't given this issue extensive thought so there may be a better or easier solution. That said, my first thought is that it wouldn't be hard to modify the org.jamwiki.search.LuceneSearchEngine.findResults() method to include Lucene's QueryFilter method to exclude topics with certain names. Alternatively you might be able to use Javascript to add an exclusion (such as "-specific_term_to_exclude") to all queries. Longer term some sort of configurable plugin system will probably need to be built, but if a quick fix is needed then this solution should (hopefully!) be enough to get you going. -- Ryan 04-Dec-2008 20:10 PST

[Edit]Single Sign On

Archived from the Feedback page:

I am looking into having a single sign on /shared authentication happening with my web site (intranet and wiki working together) They are running under the same tomcat and i saw the following comment.

"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."



But I dont really have any idea how to do this - I am new to web development. I had a bit of a read about realms and the tomcat single sign on valve but i couldn't get it to work - looks like the spring security stuff bypasses the normal security-contraint thing that tomcat realms use.... Any ideas, tips, nudges in the right direction would be helpful (I'd even be happy to have my intranet use the Jamiwiki authentication system ... )

(Sorry to flood you with questions - i saw you said you are going on holidays and just wanted to get a point in the right direction before you go - if i get it all working i'll write up the process here somewhere)

OpenID, LDAP and CAS authentication are all supported by Spring Security 2.0. I'm less sure about Tomcat realms... depending on how much time I have I'll see if I can do some investigation this evening. -- Ryan • (comments) • 26-Feb-2009 07:12 PST

[Edit]Single Sign On without going Whole Hog

I'd like to add and configure users and roles directly in JAMWiki, but only do the authentication (password validation) check via LDAP. It seems with Acegi/CAS it's either all or nothing. Is there a simple way to only do the password validation via LDAP but still manage the roles directly in JAMWiki?

Provided all logged-in users have the same rights, you could update applicationContext-security.xml and check only for IS_AUTHENTICATED_FULLY. I don't personally use LDAP, but looking through the code that looks like the only way to provide access while using LDAP only for authentication. -- Ryan • (comments) • 18-Feb-2010 20:39 PST
I'm not following you exactly. Are you saying to set access='IS_AUTHENTICATED_FULLY' on all the intercept-url patterns? --Arthur Blake 19-Feb-2010 12:24 PST
Here's an example that hopefully should clarify. Update /WEB-INF/applicationContext-security.xml as follows to allow any logged-in user (from LDAP) to edit pages: 
<intercept-url pattern="/**/Special:Edit" access="ROLE_EDIT_EXISTING,ROLE_EDIT_NEW,IS_AUTHENTICATED_FULLY" />
That's untested, but provided everything else is working properly it should allow any authenticated user to edit pages. If you wanted you could also remove the ROLE_EDIT_EXISTING and ROLE_EDIT_NEW access params, but that should be necessary to get things working. You can do the same for the other URLs that you want to provide access to. -- Ryan • (comments) • 19-Feb-2010 12:54 PST

[Edit]LDAP Users with '-' in user name can't login anymore

Archived from the Bug Reports page:

After upgrading from 0.6.7 to 0.7.2, all LDAP users that have a hyphen in their username can't login to JamWiki anymore. We have hundreds of LDAP users that have a '-c' at the end of there uid attribute to signify they are consultants.

The root cause seems to be related to line 231 in Environment.java "defaults.setProperty(PROP_PATTERN_VALID_USER_LOGIN, "([A-Za-z0-9_]+)");" Why would a hyphen in a users login be considered to be valid in the 0.6.7 release but invalid in 0.7.2? Since I haven't seen anything in the release notes documenting this change in functionality, I'm assuming this would be a regression. Would it hurt to modify the regex to include a hyphen?

It looks like the ability to configure valid login patterns was added with JAMWiki 0.6.2 back in 2007 (specifically, revision 1910); feel free to modify the regular expression in your jamwiki.properties file as needed. I'll make a note to make sure that this configuration parameter is better documented and try to figure out how it would have been reset after an upgrade. -- Ryan • (comments) • 24-Aug-2009 16:06 PDT

[Edit]adding a custom banner

Archived from the Feedback page:

I want to put a custom banner across the top of my wiki. I have searched everywhere and tried updating the css but I can not work out how to do this. Is this feature supported? If so, how can i do this?

There is no built-in support for that feature. Your best option is probably to update the /WEB-INF/jsp/wiki.jsp file and the StyleSheet topic to get the look that you want. Hope that helps! -- Ryan • (comments) • 05-Feb-2009 20:38 PST

[Edit]Configure time to auto log-out

Archived from the Feedback page:

Where would I set the time till the logged in user be automatically logged out? --tapaya 24-Mar-2009 01:15 PDT

JAMWiki should use the session timeout configured for the application server. To increase that you can either modify your application server's default settings or you can try adding the following to the /WEB-INF/web.xml file:

  <session-config>
    <session-timeout>30</session-timeout>
  </session-config>
... where "30" is the timeout in minutes. -- Ryan • (comments) • 24-Mar-2009 06:11 PDT

[Edit]Move topic missing?

Archived from the Feedback page:

I cant seem to find a way to move a topic. I searched this site and found some references to the Move tab, but I can't see it anywhere. Is it possible this is broken in the new release ? maybe I just can't find it?

It works for me locally and on jamwiki.org - the "Move" tab appears at the top of the page between "History" and "Watch". It's possible that the "move" permission has been removed - check the Special:Roles page on your wiki and verify that the appropriate group and/or user has the "ROLE_MOVE" permission. -- Ryan • (comments) • 05-Apr-2009 20:31 PDT
Thanks fixed it. I was using my own permission database and didnt have the MOVE permission in there.

[Edit]Deleted GROUP_ANONYMOUS

Archived from the Feedback page:

We managed to remove the GROUP_ANONYMOUS (somehow...) and now we cant see to find a way to get it back.

We were playing around with the Group type settings as we are trying to implement a 3 tier system of access to 2 namespace sections of information.

  1. First group has read access to Namespace 1 only (this could be anonymous users i guess)
  2. Second group has read/write access to Namespace 1 and read access to Namespace 2
  3. Third group has read/write access to everything.

Are we going about this the right way? Or is there some other way to this more effectively?

  • Sorry to be confusing, we really only need to recover the GROUP_ANONYMOUS bit, I think our other permissions will be sorted out differently.
Did you delete it from your database? You can probably just re-insert the record if necessary:
insert into jam_group ( \
      group_id, group_name, group_description \
    ) values ( \
      1, 'GROUP_ANONYMOUS', 'All non-logged in users are automatically assigned to the anonymous group.' \
    )
You may then need to restart the app server for the change to take effect. Let me know if the problem is more complex. -- Ryan • (comments) • 14-Apr-2009 17:36 PDT

Ok I think I've worked out the problem - it seems that when I removed all privileges from a category it disappeared from the list to re-assign privileges. The entry was still there in the db, so I just assigned it a single permission and it re-appeared in the GUI - thanks for the quick response.

Are you on JAMWiki 0.7.0? There was a bug (fixed in 0.7.1) that prevented roles and groups from appearing when there were no permissions assigned. It should be working now, but if there are still issues please let me know. -- Ryan • (comments) • 14-Apr-2009 20:34 PDT

[Edit]Howto change the JAMWiki Logo ??

Archived from the Feedback page:

Having my own fresh instance of JAMWiki running, I am constantly looking for information on this wiki. But this and mine look all alike. If I cound change the logo there would be far less danger of mixing them up and making changes to the wrong one. 95.112.143.34 19-Apr-2009 13:12 PDT

Have a look at Configuration, which covers most of the configurable settings for the wiki. The logo can be changed from the third field on Special:Admin. If there is a better / more obvious way to document this functionality any feedback is appreciated, or if you're willing feel free to directly edit the pages in question. -- Ryan • (comments) • 19-Apr-2009 14:55 PDT

[Edit]Password storage in Database

Archived from the Feedback page:

Hi, In order to have a high degree of security , I could see that Jamwiki is using Encrypted password. But in my system , there are some windows applications which is using User ID/Password from the "Jam_wiki_user_info' table for authentication. Please let me know how to decode the password from the table so that other Windows applications can also use it. It would be very much helpful for other developers in my system to have unique database for authentication. Thanks in Advance !!!... --Venkat Raman 04-Aug-2009 03:57 PDT

Passwords are encrypted using a one-way algorithm so that they cannot be unencrypted - allowing password decryption would be a security hole. If you would like to share passwords you can either encrypt the password prior to comparing against the database value using org.jamwiki.utils.Encryption.encrypt(), or you could implement an LDAP solution to store logins and passwords, and then configure JAMWiki to access that database - see Configuration#LDAP / CAS / OpenID. -- Ryan • (comments) • 04-Aug-2009 06:44 PDT
Thanks Ryan. I'm using Jamwiki 0.6.6 . I'm a new user of LDAP. Using LDAP, is it possible to control roles/access based on each user? Is it possible to validate users with edit access ,the one with view access and the one with admin access. Please help me so that I can go ahead and use LDAP authentication.--Venkat Raman 04-Aug-2009 20:19 PDT
JAMWiki 0.7.0 has a more complete integration with Spring Security and offers an easier LDAP integration. Roles, userids and passwords can all be controlled via LDAP - see Wikipedia's article on LDAP for a high-level overview. -- Ryan • (comments) • 05-Aug-2009 07:47 PDT
I have a similar issue. I encrypted the password with SHA-512. However, the encryption does not match with that of the database. Also, encryption-algorithm is SHA-512 in the database, while org.jamwiki.utils.Encryption.encrypt() says SHA-512 is not supported


[Edit]I have forgotten my (administrtor) password.

Archived from the Feedback page:

How can I set a new one? 93.132.179.189 02-Jan-2010 06:08 PST

If you have another account with admin rights you can reset the admin password from the Special:Maintenance page, otherwise the only possible way to reset the admin password is to go into the database and set the password field of the jam_users table to the password of another account that you DO know the password for, such as update jam_users set password = (select password from jam_users where username = 'johndoe') where username = 'admin'. -- Ryan • (comments) • 02-Jan-2010 07:46 PST
Thank you. Can this be done even in case of an internal DB? And if so, how? (The contents is small in this case and there would not be too much damage if I had to export and reimport the wiki so the question is more for curiosity.) 93.132.142.199 03-Jan-2010 02:21 PST
You can search online for tools that will allow you to connect to an HSQL database. The connection settings will be: org.hsqldb.jdbcDriver, jdbc:hsqldb:file:path-to-your-database-files;shutdown=true, sa / blank password. -- Ryan • (comments) • 04-Jan-2010 02:02 PST

This doesn't seem to work:

  /home/myuser/wurstel/database:
 total used in directory 1072 available 132968180
 drwxr-xr-x 16 myuser myuser    4096 2010-01-04 12:44 ..
 drwxr-xr-x  2 myuser myuser    4096 2010-01-04 12:42 .
 -rw-r--r--  1 myuser myuser   16899 2010-01-03 16:44 jamwiki.backup
 -rw-r--r--  1 myuser myuser     418 2010-01-03 16:44 jamwiki.properties
 -rw-r--r--  1 myuser myuser    8275 2010-01-03 16:44 jamwiki.script
 -rw-r--r--  1 myuser myuser 1048576 2010-01-03 15:43 jamwiki.data

from ~/sqltool.rc

# A test db
urlid jm
url jdbc:hsqldb:file:/home/myuser/wurstel/database
username sa
password

from the shell:

myuser@Munin:~/workspace1/Hsqldb$ java -jar /home/myuser/workspace1/Hsqldb/lib/hsqldb.jar jm
JDBC Connection established to a HSQL Database Engine v. 1.9.0 database
as "SA" with R/W TRANSACTION_READ_COMMITTED Isolation.
SqlTool v. 1155.                        (SqlFile processor v. 1156)
Distribution is permitted under the terms of the HSQLDB license.
(c) 2004-2009 Blaine Simpson and the HSQL Development Group.

   \q    to Quit.
   \?    lists Special Commands.
   :?    lists Edit-Buffer/History commands.
   *?    lists PL commands.
   /?    displays help on how to set and use macros (command aliases).

SPECIAL Commands begin with '\' and execute when you hit ENTER.
EDIT-BUFFER / HISTORY Commands begin with ':' and execute when you hit ENTER.
PROCEDURAL LANGUAGE commands begin with '*' and end when you hit ENTER.
MACRO executions and definitions begin with '/' and end when you hit ENTER.
All other lines comprise SQL Statements (or comments).
 SQL Statements are terminated by either unquoted ';' (which executes the
 statement), or a blank line (which moves the statement into the edit buffer
 without executing).
After turning on variable expansion with command "*" (or any other PL
command), PL variables may be used in most commands like so:  *{PLVARNAME}.
Be aware when using regular expressions on commands, that the regex.s
operate only on the command text after the * or \ prefix, if any.

sql> \dt
TABLE_SCHEM  TABLE_NAME
-----------  ----------

Fetched 0 rows.
sql>

Would that really work with an internal DB or do I just have some parameter settings wrong? 95.112.137.144 04-Jan-2010 03:53 PST

Great!!! It works!!!

The parameter settings in ~/sqltool.rc need to be:

# A test db
urlid jm
url jdbc:hsqldb:file:/home/myuser/wurstel/database/jamwiki
username sa
password

95.112.137.144 04-Jan-2010 04:03 PST

Well, not this great as I thought. While I can connect directly now, jamwiki can't connect any more: 
A connection could not be established with the database; please re-check the settings: Wrong database file version
It was a test wiki, so no valuable contents is lost but this should be a warning to other users to be careful and first copy everything to a far away save place. I will post again in case I can fiddle out how to make it work again. 95.112.137.144 04-Jan-2010 04:19 PST
To put my jamwiki back to life all I had to do was to replace the file jamwiki.properties with the old version which could be generated by directing it to a different file-system directory in the Special:setup. It realy is not an issue of jamwiki but of hsql. 95.112.137.144 04-Jan-2010 07:01 PST
Thanks for the additional info - I'll try to integrate this into the existing documentation soon. -- Ryan • (comments) • 04-Jan-2010 22:56 PST

[Edit]Need help with LDAP setup

Archived from the Feedback page:

I configured the LDAP setup in applicationContext-security.xml. I can successfully authenticate with this configuration but I am not authorized to do anything. Also, with this setup I can no longer login as the admin user I created at setup time. I'd like anonymous users to not be able to view or edit anything and users authenticated via LDAP to be able to do anything. Please Help.

Make sure your LDAP system is assigning ROLE_ADMIN to your admin user login. In addition, all of the roles specified on Special:Roles must be assigned to users via LDAP... if your LDAP system is using different roles simply create new roles from the Special:Roles interface. Hope that helps! -- Ryan • (comments) • 11-May-2009 18:46 PDT

ok here's what I did for anyone following. FWIW, I'm using openLDAP. I created an organization unit "ou=jamwiki,ou=groups,dc=example,dc=com". I then created the following groups underneath the jamwiki ou (ADMIN, EDIT_EXISTING, EDIT_NEW, MOVE, SYSADMIN, TRANSLATE, UPLOAD, VIEW). Then I modified the applicationContext-security.xml as such:

<ldap-server id="ldapServer" url="ldap://localhost/dc=example,dc=com" port="389" manager-dn="cn=admin,dc=example,dc=com" manager-password="*********" />
<ldap-authentication-provider server-ref="ldapServer" group-search-filter="member={0}" group-search-base="ou=jamwiki,ou=groups" user-search-filter="uid={0}" user-search-base="ou=people" user-dn-pattern="cn={0},ou=people" />
<authentication-provider>
	<ldap-user-service server-ref="ldapServer" group-search-filter="member={0}" group-search-base="ou=jamiwiki,ou=groups" user-search-filter="uid={0}" user-search-base="ou=people" />
</authentication-provider>

I also set the "useJAMWikiAnonymousRoles" property to false in the applicationContext-security.xml Then restart server.

The best I can tell, the "built-in" GROUP_REGISTERED_USER does not apply when using LDAP, so you have to add every user to every group created above manually. I would like to find a way to have jamwiki utilize my existing LDAP "developer" group and somehow assign roles to the developer group. Any ideas how I might achieve that?

First, my knowledge of LDAP is limited and the initial JAMWiki integration was done using samples from the Spring Security examples. That said, I believe that the Spring LDAP integration should automatically pick up all groups, roles, etc that are assigned in your LDAP system, so if you configure LDAP with a permission of (for example) JAMWIKI_ADMIN and the modify /WEB-INF/applicationContext-security.xml to look for JAMWIKI_ADMIN that users who get that permission will be able to to access resources allowed by that permission. Also, as you've indicated, something like GROUP_REGISTERED_USER will no longer apply when using LDAP since the default authentication provider is no longer being used.
Does that help? If so then I'd like to use the information from this discussion to update Configuration#LDAP / CAS / OpenID so that hopefully this sort of integration will be easier for others in the future. -- Ryan • (comments) • 12-May-2009 21:33 PDT

I'll have to give that a shot in a test environment. I've already deployed using the setup I created

Hi. Because of design of my corporate LDAP tree I can't use group names as already created in JAMWIKI (e.g. group called ADMIN). Thus I wonder if there is possibility to map some LDAP group names (or role names found in LDAP) to those used in JAMWIKI. If not what would be the best way to add such a feature. Is modification of JAMWikiPostAuthenticationFilter good idea to acomplish this? -- Seba

I don't use LDAP regularly, but I believe that you should simply be able to modify the role names in /WEB-INF/applicationContext-security.xml to match the roles assigned by your LDAP system. If that doesn't work let me know and I'll read through the Spring Security configuration docs to see if there's a better solution. -- Ryan • (comments) • 10-Nov-2009 07:48 PST

Hello, I wanted to add my experiences here so others can save some time on LDAP setup. I was able to mostly integrate with my company's LDAP setup. I work at an office with thousands of employees and so I had absolutely no personal access to the backend LDAP stuff and had to figure it out through trial and error. Your statement above is absolutely correct. If you modify the role names in /WEB-INF/applicationContext-security.xml you can get it working. However, one absolutely vital point is that by default Spring Security will prepend 'ROLE_' to any groups you get back from LDAP as well as putting the entire name in upper case. This means that if my LDAP group is 'JAMWikiAdmin' it will actually come back from Spring as 'ROLE_JAMWIKIADMIN'. So when you are modifying your /WEB-INF/applicationContext-security.xml you must prepend 'ROLE_'. Spaces seem to be left intact, for example 'JamWiki Admin' ends up coming back as 'ROLE_JAMWIKI ADMIN'.

Here is an example of the applicationContext-security.xml file. This assumes you have two 'groupOfUniqueNames' in LDAP: JamWikiUser and JamWikiAdmin. There may be better, cleaner ways of setting this up but this is the best I could do:

                <intercept-url pattern="/**/Special:Admin" access="ROLE_JAMWIKIADMIN" />
                <intercept-url pattern="/**/Special:Edit" access="ROLE_JAMWIKIUSER" />
                <intercept-url pattern="/**/Special:Import" access="ROLE_JAMWIKIUSER" />
                <intercept-url pattern="/**/Special:Login" access="IS_AUTHENTICATED_ANONYMOUSLY" />
                <intercept-url pattern="/**/Special:Maintenance" access="ROLE_JAMWIKIADMIN" />
                <intercept-url pattern="/**/Special:Manage" access="ROLE_JAMWIKIADMIN" />
                <intercept-url pattern="/**/Special:Move" access="ROLE_JAMWIKIUSER" />
                <intercept-url pattern="/**/Special:RecentChangesFeed" filters="none" />
                <intercept-url pattern="/**/Special:Roles" access="ROLE_JAMWIKIADMIN" />
                <intercept-url pattern="/**/Special:Setup" filters="none" />
                <intercept-url pattern="/**/Special:Translation" access="ROLE_JAMWIKIADMIN" />
                <intercept-url pattern="/**/Special:Upload" access="ROLE_JAMWIKIADMIN" />
                <intercept-url pattern="/**/Special:Upgrade" filters="none" />
                <intercept-url pattern="/**/*.jsp" filters="none" />
                <intercept-url pattern="/**/*.css" filters="none" />
                <intercept-url pattern="/images/**" filters="none" />
                <intercept-url pattern="/js/**" filters="none" />
                <intercept-url pattern="/upload/**" filters="none" />
                <intercept-url pattern="/**" access="ROLE_JAMWIKIUSER" />

I hope this helps. This was found by a co-worker while digging through the Spring Security docs. It is possible to turn off this prepending of 'ROLE_'. Please see this page for more information. Look under point '10.3.3. Loading Authorities'.

I was able to lock down my wiki so only users authenticated with LDAP will even be able to see any page, which is important for my team.

I do have one issue, though: even though the rest of my permissions are working without issues I cannot seem to allow editing on any page for any kind of user! It is very frustrating. Every other pattern above matches correctly but editing will just not work with anything I do. Ryan, is there something special about editing in the security setup? Looking through the source in ServletUtil in the 'isEditable' method you check hard-coded constant variables, i.e. Role.ROLE_EDIT_NEW. This means that in LDAP you cannot fully integrate unless you enter 'EDIT_NEW' as a group in LDAP, which I can't do as I mentioned previously. I am working on re-building the source after changing the constants in the 'Role' class because I think that is the correct fix but would it be possible to somehow make this more generic so it will integrate with LDAP without having to add those groups? Like I said I have very little access to the backend LDAP.

I would like to say that the code is very well written. I easily found the code that I needed, which is a testament to your overall design. Well done! -- ptrimbl • 01-Feb-2010 09:52 CST

Thanks for the feedback - I'm officially supposed to be working on getting a sandbox ready for a demo right now so I haven't read through your comment in detail, but see Configuration#LDAP / CAS / OpenID for some quirks with Spring Security and patterns requiring query parameters that might help solve the problem you're facing. -- Ryan • (comments) • 01-Feb-2010 11:44 PST
Hi Ryan, just FYI, I was able to modify the code in the Role and Environment classes in my own copy to pull the role info from the jamwiki.properties file. However, it seems like the applicationContext-security.xml file has changed in the most recent version. I think that the Configuration#LDAP / CAS / OpenID page needs to be to be updated to reflect any changes. I'll try to figure out what changed and how to modify it to make LDAP work again. -- ptrimbl • 02-Feb-2010 09:55 CST
Actually, to be honest, I am seeing a difference between the source .zip file and svn source from pretty far back (the 2009-11-29 commit). Why is the source from your downloads page different from the source tagged as '0.8.2' in svn? I download the latest war file and the applicationContext-security.xml is different from anything I can find in svn. I am hopefully just missing something very obvious. I am pretty new to svn. -- ptrimbl • 02-Feb-2010 13:16 CST
The current SVN trunk will be significantly different from the 0.8.2 code as that is the development code for the 0.9.0 release and includes a Spring Framework and Spring Security update, amongst a few hundred other changes. The 0.8.2 code is in tags/release-0.8.2, and the live branch (which will become 0.8.3) is under branches/0.8.x.
Some quick setup tips - to download the 0.8.x development branch, SVN checkout the https://jamwiki.svn.sourceforge.net/svnroot/jamwiki/wiki/branches/0.8.x URL. If you're on Windows, Tortoise SVN is an invaluable front-end for working with SVN. Hope that helps! -- Ryan • (comments) • 02-Feb-2010 11:40 PST
Thanks so much, Ryan, for all of the help. It worked! I understand the difference between the trunk and the branch now. That was definitely my problem. It works fully now. I made the changes (in the old 0.8.2 code) to Role.java and Environment.java to pick up the 'ROLE_' strings from jamwiki.properties and I was able to fully configure the applicationContext-security.xml file to connect to LDAP.
I think I will take some time to fully understand the changes that were made for the 0.9 code and see if I can make LDAP work again. If I manage to get it working I guess I can start thinking about making the minor changes available to others, but...to be honest I'm a little afraid of gaining any kind of access to Subversion since I am so new to it. I'm sure that you have all sorts of safeguards against people committing changes incorrectly but I would want to make sure I was fully comfortable (or at least assured that I couldn't do any damage) before trying to apply the changes I mentioned above. Thanks again for all the support. -- ptrimbl • 02-Feb-2010 15:10 CST
The usual practice with Subversion is to have someone create their own branch (see How to Help#How to contribute) that they can then play around with. This approach allows other developers to view changes without any impact on trunk or production branches. Once (or if) the branch changes are reviewed and ready to merge then it's a fairly simple matter to integrate them into trunk or the appropriate production branch. In any case, I'll try to find some time to look into this issue as well, so even if it isn't your code, hopefully 0.9.x will have a fix for this issue :) -- Ryan • (comments) • 02-Feb-2010 13:48 PST
I'm having the same problem. I just want all users authenticated through LDAP to have access to Special:Edit. So I used the 'IS_AUTHENTICATED_REMEMBERED' value. That didn't work so I even tried the 'IS_AUTHENTICATED_ANONYMOUSLY' value. Still no ability to edit. Any idea how to fix this?--ericma 07-May-2010 12:07 PDT
Can you post your intercept-url patterns from the /WEB-INF/applicationContext-security.xml file? I don't personally use LDAP so this one might be difficult for me to figure out, but a number of people have had success so hopefully it's a simple fix. Additionally, if this does get fixed and you're willing to update the documentation on the Configuration#LDAP / CAS / OpenID page with your experiences I'd be very grateful :) -- Ryan • (comments) • 07-May-2010 13:53 PDT
Here are my intercept-url patterns:
		<intercept-url pattern="/**/Special:Admin" access="IS_AUTHENTICATED_REMEMBERED" />
		<intercept-url pattern="/**/Special:Edit" access="IS_AUTHENTICATED_REMEMBERED" />
		<intercept-url pattern="/**/Special:Import" access="IS_AUTHENTICATED_REMEMBERED,ROLE_IMPORT" />
		<intercept-url pattern="/**/Special:Login" access="IS_AUTHENTICATED_REMEMBERED,IS_AUTHENTICATED_ANONYMOUSLY" />
		<intercept-url pattern="/**/Special:Maintenance" access="IS_AUTHENTICATED_REMEMBERED,ROLE_SYSADMIN" />
		<intercept-url pattern="/**/Special:Manage" access="IS_AUTHENTICATED_REMEMBERED,ROLE_ADMIN" />
		<intercept-url pattern="/**/Special:Move" access="IS_AUTHENTICATED_REMEMBERED,ROLE_MOVE" />
		<intercept-url pattern="/**/Special:RecentChangesFeed" filters="none" />
		<intercept-url pattern="/**/Special:Roles" access="IS_AUTHENTICATED_REMEMBERED" />
		<intercept-url pattern="/**/Special:Setup" filters="none" />
		<intercept-url pattern="/**/Special:Translation" access="IS_AUTHENTICATED_REMEMBERED,ROLE_TRANSLATE" />
		<intercept-url pattern="/**/Special:Upload" access="IS_AUTHENTICATED_REMEMBERED" />
		<intercept-url pattern="/**/Special:Upgrade" filters="none" />
		<intercept-url pattern="/**/*.jsp" filters="none" />
		<intercept-url pattern="/**/*.css" filters="none" />
		<intercept-url pattern="/images/**" filters="none" />
		<intercept-url pattern="/js/**" filters="none" />
		<intercept-url pattern="/upload/**" filters="none" />
		<intercept-url pattern="/**" access="IS_AUTHENTICATED_REMEMBERED" />
		<remember-me key="jam35Wiki" />
		<anonymous key="jam35Wiki" />
Your patterns looks correct, and I did some reading of the Spring Security docs including some relevant threads such as http://forum.springsource.org/showthread.php?t=75478, and I can't see what would be going wrong provided authentication is successful. So, that said, are you sure that it's connecting to your LDAP server and authenticating properly? Apologies for not being more help, but I'm not particularly knowledgeable about LDAP configuration. -- Ryan • (comments) • 12-May-2010 19:39 PDT
I'm pretty sure that it's connecting to my LDAP and authenticating. I'm using my LDAP username and password and it let's me in. Name and password combinations that are not in the LDAP do not work. This LDAP is used for our email system amongst others. Also when I make adjustments to the intercept-url patterns they work appropriately for the user logins. The only thing that doesn't work is creating and editing files.--ericma 14-Jun-2010 12:42 PDT
Thanks for the follow-up. I'll try to set aside some time this weekend to investigate a bit more and see if I can help out in any way. Sorry for your trouble! -- Ryan • (comments) • 16-Jun-2010 07:28 PDT

[Edit]File Uploads

Archived from the Feedback page:

I've set my file upload directory to be /opt/jamwiki-data/files I've set Relative File Upload Root to /jamwiki/upload/ I can upload files. Files make it into /opt/jamwiki-data/files. However, the links to the files give me 404. The link is to http://mydomain.com:8080/jamwiki/upload/2009/5/image.png. So I created a symlink in $GLASSFISH_HOME/domains/domain1/applications/jamwiki/upload to /opt/jamwiki-data/files but I still get 404 errors. Any idea what I can try.

This sounds like an app server issue rather than a JAMWiki issue. I use a similar setup to what you've described on jamwiki.org, with file uploads going to the Apache docroot, and I know a number of sites use this functionality without issue. Configuration#File upload settings has some information, but it sounds like you've got the JAMWiki configuration correct so I'd try to figure out if Glassfish is actually following the symlink. -- Ryan • (comments) • 13-May-2009 11:59 PDT

In case anyone suffers similar problem in glassfish. following symlinks is disabled in glassfish by default. You can enable this by editing glassfish domain.xml and allow symlink following. Find this section and add the allowLinking property as shown

	<virtual-server id="server" http-listeners="http-listener-1,http-listen......>
	  <property name="docroot" value="${com.sun.aas.instanceRoot}/docroot" />
          <property name="accesslog" value="${com.sun.aas.instanceRoot}/logs/ac$....../>
	  <property name="sso-enabled" value="false" />
	  <property name="allowLinking" value="true" />
	</virtual-server>

[Edit]Single_sign-on (SSO)

Archived from the Feedback page:

Does JAMWikie support SSO (http://en.wikipedia.org/wiki/Single_sign-on) compatible with http://jforum.net/doc/SSO

Single sign-on is supported via Spring Security. -- Ryan • (comments) • 23-Jul-2010 19:19 PDT

[Edit]Setting up a "private" wiki

Archived from the Feedback page:

I've got an installation of 0.8.0 running in Resin. (Congrats on the 0.8.0 release btw, it's excellent.) I want to set it up so that only logged-in users can see the content, ideally something along the lines of what you'd get with HTTP authentication turned on for HTML pages (although the solution does not have to involve HTTP authentication.) So what would be the best-practice way of doing that? I looked in Tech comments:User Permissions and Tech:User Permissions but didn't see anything on this. --Floating World 12-Dec-2009 10:42 PST

I need to add an informational page on access control :) I have a personal wiki that is read-protected (this sounds like what you want) by disabling all permissions for GROUP_ANONYMOUS on Special:Roles. Note that if anonymous permissions are removed then there will NOT be a way for new users to register - if you want to create new user accounts you would need to re-enable ROLE_VIEW permissions for anonymous users, register the new account, then again disable ROLE_VIEW - there is an open feature request to make that process less clunky, but it hasn't yet been implemented. Modifying /WEB-INF/classes/applicationContext-security.xml offers additional opportunities to customize login options. -- Ryan • (comments) • 13-Dec-2009 18:43 PST
I'm also trying to set up a private wiki for a small IT group to share information. When I remove all roles from GROUP_ANONYMOUS, the default page starts auto-redirecting to jamwiki/null/Special:Login which gets a 404 not found. I have to manually change the "null" to "en" in my browser address bar to get back into the wiki. I think this is a bug... Another issue is that the LeftMenu entries on the left side of the page are still visible even without logging in... (I don't want anonymous users to see *anything* but the logon form) Both issues exist on 0.8.2 and trunk build (as of yesterday.) --Arthur Blake 19-Feb-2010 14:11 PST

[Edit]JAMWiki behind Proxy Pass

Archived from the Feedback page:

Hi ! Currently I have jamwiki configured with Apache2 and Proxy Pass.... but when anonymous user edit something always I get IP 127.0.0.1, only for be sure, what is the correct configuration on Tomcat to get IP Address from anonymous user behind Proxy Pass? —The preceding comment was added by jotadeveloper (comments • contribs) .

Unless I'm misunderstanding I think this question is about your proxy configuration rather than about JAMWiki, and thus not something that I can answer. Please let me know if I've misunderstood. -- Ryan • (comments) • 25-Jul-2010 08:57 PDT
use a filter to get X-forwarded header, to get client's IP. By default, all proxy, cache's will put the client ip there. And this is the way I deal with it. jack 01-Aug-2010 12:08 PDT

[Edit]0.9.1 alternative LDAP setup

Archived from the Feedback page:

So I've been trying to find a way to get the user authenticated via LDAP, but have the roles/authorities pulled from the database. I think I have a working solution. First off, the LDAP sample setup in the latest verison is incorrect. All the ldap tags in the XML have to be enclosed in the "authentication-mangaer" tag. Easy fix, but in order to get this working, you can't use the predefined ldap tags.

The current config for 0.9.1 looks like this:

<authentication-manager alias="authenticationManager">
	<authentication-provider user-service-ref="jamWikiAuthenticationDao">
		<password-encoder ref="jamwikiPasswordEncoder" />
	</authentication-provider>		
</authentication-manager>

This tells Spring Security to use the user service: org.jamwiki.authentication.JAMWikiDaoImpl referenced by the id "jamWikiAuthenticationDao". This allows Spring Security to call the "UserDetails loadUserByUsername(String username)" method and if it returns a UserDetails object (WikiUserDetailsImpl implementation), the user has been authenticated.

In order to get Spring Security to authenticate via LDAP, you have to setup the LDAP authenticator similar to the provided example. However, using this method, all the roles for a user are pulled from their LDAP group membership. This causes lots of issues with authorization in JamWiki due to hard-coded role strings in the JamWiki code (see org.jamwiki.servlets.ServletUtil...specifically the "isEditable" method).

So like I said, I was trying to figure out a way to authenticate the user using LDAP bind authentication, but pull roles from the JamWiki database. Using Spring and its dependency injection, I knew this was possible so I went searching for a way to do it. The solution I found is outlined below. I hope this helps folks.

<authentication-manager alias="authenticationManager">
	<authentication-provider ref="ldapAuthProvider" user-service-ref="jamWikiAuthenticationDao" />
</authentication-manager>

<b:bean id="ldapAuthProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
	<b:constructor-arg><b:ref bean="ldapAuthenticator"/></b:constructor-arg>
	<b:constructor-arg><b:ref bean="ldapAuthoritiesPopulator"/></b:constructor-arg>
</b:bean>
<b:bean id="ldapAuthenticator" class="org.springframework.security.ldap.authentication.BindAuthenticator">
	<b:constructor-arg><b:ref bean="ldapContextSource"/></b:constructor-arg>
	<b:property name="userSearch" ref="ldapUserSearch" />
</b:bean>
<b:bean id="ldapAuthoritiesPopulator" class="org.springframework.security.ldap.authentication.UserDetailsServiceLdapAuthoritiesPopulator">
	<b:constructor-arg><b:ref bean="jamWikiAuthenticationDao"/></b:constructor-arg>
</b:bean>
<b:bean id="ldapContextSource" class="org.springframework.ldap.core.support.LdapContextSource">
	<b:property name="url" value="${ldap-url}:${ldap-port}" />
	<b:property name="userDn" value="${manager-dn}" />
	<b:property name="password" value="${manager-password}" />
	<b:property name="referral" value="follow" />
</b:bean>
<b:bean id="ldapUserSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
	<b:constructor-arg><b:value>${user-search-base}</b:value></b:constructor-arg>
	<b:constructor-arg><b:value>${user-search-filter}</b:value></b:constructor-arg>
	<b:constructor-arg><b:ref bean="ldapContextSource"/></b:constructor-arg>
</b:bean>
Thanks for this - if you'd like to update the Configuration page with this info please do - I don't use LDAP so my knowledge on the subject is limited. I'll also get the sample config updated for JAMWiki 0.9.2 - if you would like a credit in the changelog please let me know what name to use. -- Ryan • (comments) • 11-Aug-2010 14:00 PDT

Thanx - my name is Bobby Lawrence.

I'd also like to point out that I basically keep the default Stylesheet except for one declaration and I'd like to suggest that it be set as the default for upcoming versions of the software.

The default value for the "content-article pre" declaration is currently set to "overflow: hidden;". The "pre" tag is very useful in the wiki, but many times, the text on a line inside a pre tag gets to long to display on the screen due to width and therefore the text is cut off because of the fact that the overflow property is set to 'hidden'.

I find myself always having to update this to "overflow: auto;" or "overflow: scroll;". This causes the browser to put in a scroll bar for those pre elements whose content is to long to display on the screen due to its width. Like I said, it would be nice if this was the default, but not a big deal as it is easily updated.

Thanks. I should have some time to do updates this weekend and will get your changes committed. I probably won't change the stylesheet for the 0.9.x series since I try to limit changes in the current release branch to bugfixes, but will look into updating it for 1.0.x. I've gone back and forth on how to handle the pre tag - I don't want the screen to resize, so a scroll bar is probably the least-bad alternative. -- Ryan • (comments) • 12-Aug-2010 07:17 PDT
revision 3162 adds your configuration example to the code in the 0.9.2 branch. I'll look at the stylesheet issue shortly - thanks again! -- Ryan • (comments) • 14-Aug-2010 19:20 PDT

[Edit]using a http element instead of a registered user - or - simple username matching

Archived from the Feedback page:

Hello, I am playing around with JamWIKI, but I have some issues regarding the authentication. In all of my http requests I have a user entered ( userid=123 ), so I would like to ignore all the registration part of JamWIKI to allow all of my users to edit everything, but save the userid additionally to the ip-address. I assume it can be matches via the spring security configuration, but I am no Java developer and all examples I have found on this site and at the springsecurity site don't help. Is there anyone who can give me a short example which could solve that or which has a similar setup which I could adapt ?

I don't think that there is a simple way to do what you want, but it sounds like you will need to implement your own version of org.springframework.security.core.userdetails.UserDetailsService and use it in place of org.jamwiki.authentication.JAMWikiDaoImpl. -- Ryan • (comments) • 18-Oct-2010 20:16 PDT

[Edit]Can't start jamwiki with siteminder configuration (wrong config?)

Archived from the Feedback page:

(I have updated this whole feedback, so please have a look again)

I would like to use jamwiki with siteminder (SSO) authentication. The documentation which is partly found here and on the spring security website, brought me to following configuration XML. There must be something completely broken in my config, as tomcat is reporting following error when I want to start it up:

INFO: Deploying web application archive jamwiki-0.9.3.war
Oct 19, 2010 5:08:32 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Oct 19, 2010 5:08:32 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/jamwiki-0.9.3] startup failed due to previous errors
Oct 19, 2010 5:08:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/jamwiki-0.9.3] appears to have started a thread named [net.sf.ehcache.CacheManager@7ba2a618] but has failed to stop it. This is very likely to create a memory leak.
Oct 19, 2010 5:08:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/jamwiki-0.9.3] appears to have started a thread named [net.sf.ehcache.CacheManager@a5bdce3] but has failed to stop it. This is very likely to create a memory leak.

If I switch back to the original applicationContext-security.xml, jamwiki starts up fine and works as expected, but without siteminder support.

Here is my applicationContext-security.xml. It is my first webapp xml ever, so please excuse if I made newbee errors:

<?xml version="1.0" encoding="UTF-8"?>

<b:beans xmlns="http://www.springframework.org/schema/security"
    xmlns:b="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">

	<!--
	This section contains the basic Spring Security configuration settings.  The intercept-url elements
	define what URLs are protected and what permission is required to access those URLs.  The remember-me
	element enables a cookie to be stored to remember user logins across sessions, and the anonymous
	element implements Spring Security's basic anonymous user permissions - note that these will be updated
	by the JAMWikiAnonymousProcessingFilter.
	-->
	<http auto-config="false" entry-point-ref="authenticationEntryPoint">
		<!--
		The intercept-url element defines the roles or authentication states that are required
		to access a URL path.  Roles should be comma-delimited.  To restrict pages by user type
		instead of user role the following values can be used:
		  * IS_AUTHENTICATED_ANONYMOUSLY - Allow access to any user.
		  * IS_AUTHENTICATED_REMEMBERED - Allow access to logged-in users or users with a "remember me" cookie.
		  * IS_AUTHENTICATED_FULLY - Allow access to logged-in users.
		To remove all Spring Security processing from a page use the filters="none" attribute.
		-->
		<intercept-url pattern="/**/Special:Admin" access="ROLE_SYSADMIN" />
		<intercept-url pattern="/**/Special:Edit" access="ROLE_EDIT_EXISTING,ROLE_EDIT_NEW" />
		<intercept-url pattern="/**/Special:Import" access="ROLE_IMPORT" />
		<intercept-url pattern="/**/Special:Login" access="IS_AUTHENTICATED_ANONYMOUSLY" />
		<intercept-url pattern="/**/Special:Maintenance" access="ROLE_SYSADMIN" />
		<intercept-url pattern="/**/Special:Manage" access="ROLE_ADMIN" />
		<intercept-url pattern="/**/Special:Move" access="ROLE_MOVE" />
		<intercept-url pattern="/**/Special:RecentChangesFeed" filters="none" />
		<intercept-url pattern="/**/Special:Roles" access="ROLE_SYSADMIN" />
		<intercept-url pattern="/**/Special:Setup" filters="none" />
		<intercept-url pattern="/**/Special:Translation" access="ROLE_TRANSLATE" />
		<intercept-url pattern="/**/Special:Upload" access="ROLE_UPLOAD" />
		<intercept-url pattern="/**/Special:Upgrade" filters="none" />
		<intercept-url pattern="/**/Special:VirtualWiki" access="ROLE_SYSADMIN" />
		<intercept-url pattern="/**/*.jsp" filters="none" />
		<intercept-url pattern="/**/*.css" filters="none" />
		<intercept-url pattern="/images/**" filters="none" />
		<intercept-url pattern="/js/**" filters="none" />
		<intercept-url pattern="/upload/**" filters="none" />
		<intercept-url pattern="/**" access="ROLE_VIEW" />
		<access-denied-handler ref="jamwikiAccessDeniedHandler" />
		<remember-me key="jam35Wiki" services-alias="_rememberMeServices" />
		<anonymous key="jam35Wiki" />
		<!-- note that the JAMWiki LoginServlet will add the appropriate logout success URL to the request during logout -->
		<logout />
		<custom-filter position="FORM_LOGIN_FILTER" ref="authenticationProcessingFilter" />
		<custom-filter before="EXCEPTION_TRANSLATION_FILTER" ref="jamwikiPostAuthenticationFilter" />
		<custom-filter position="PRE_AUTH_FILTER" ref="siteminderFilter" />
	</http>

      	<b:bean id="siteminderFilter" class="org.springframework.security.web.authentication.preauth.header.RequestHeaderAuthenticationFilter">
   	  	<b:property name="principalRequestHeader" value="SM_USER"/>
   		<b:property name="authenticationManager" ref="authenticationManager" />
 	</b:bean>

	<b:bean id="preauthAuthProvider" class="org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider">
    		<b:property name="preAuthenticatedUserDetailsService">
     		 	<b:bean id="userDetailsServiceWrapper" class="org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper">
        			<b:property name="userDetailsService" ref="userService"/>
      			</b:bean>
    		</b:property>
    	</b:bean>

	<!--
	The authentication processing filter controls where a user will be sent when he tries to
	access a protected URL and how that user will be authenticated after trying to login.
	-->
	<b:bean id="authenticationProcessingFilter" class="org.jamwiki.authentication.JAMWikiAuthenticationProcessingFilter">
		<b:property name="authenticationManager" ref="authenticationManager" />
		<b:property name="authenticationFailureHandler" ref="authenticationFailureHandler" />
		<!-- do not include virtual wiki in the url, JAMWikiAuthenticationProcessingFilter adds it -->
		<b:property name="filterProcessesUrl" value="/j_spring_security_check" />
		<b:property name="rememberMeServices" ref="_rememberMeServices" />
	</b:bean>


	<!--
	The authentication provider is the element which is passed user login attempts for verification.
	-->
	<authentication-manager alias="authenticationManager">
		 <authentication-provider ref="preauthAuthProvider" />
	</authentication-manager>
	<b:bean id="authenticationFailureHandler" class="org.jamwiki.authentication.JAMWikiAuthenticationFailureHandler">
		<!-- do not include virtual wiki in the url, JAMWikiAuthenticationFailureHandler adds it -->
		<b:property name="authenticationFailureUrl" value="/Special:Login?message=error.login" />
	</b:bean>
	    
	<!-- Try to include a simple setup for userDetails -->
	<user-service id="userService">
        	<user name="admin_user" password="rod" authorities="ROLE_ADMIN,ROLE_SYSADMIN,ROLE_USER" />
        	<user name="user_user" password="dianne" authorities="ROLE_USER" />
    	</user-service>


	<!--
	The error message provider adds a page-specific error message to be used when a user is denied
	access to a page.  For example, a different error is shown to users who are not allowed to edit
	a page than to those who are denied access to the admin pages.
	-->
	<b:bean id="jamwikiErrorMessageProvider" class="org.jamwiki.authentication.JAMWikiErrorMessageProvider">
		<b:property name="urlPatterns">
			<b:map>
				<b:entry key="/**/Special:Admin" value="login.message.admin" />
				<b:entry key="/**/Special:Edit" value="login.message.edit" />
				<b:entry key="/**/Special:Maintenance" value="login.message.admin" />
				<b:entry key="/**/Special:Manage" value="login.message.admin" />
				<b:entry key="/**/Special:Move" value="login.message.move" />
				<b:entry key="/**/Special:Roles" value="login.message.admin" />
				<b:entry key="/**/Special:Translation" value="login.message.admin" />
				<b:entry key="/**/Special:VirtualWiki" value="login.message.admin" />
				<b:entry key="/**/*" value="login.message.default" />
			</b:map>
		</b:property>
	</b:bean>

	<!--
	This method adds any message from the errorMessageProvider to the redirect.
	-->
	<b:bean id="jamwikiAccessDeniedHandler" class="org.jamwiki.authentication.JAMWikiAccessDeniedHandler">
		<b:property name="errorMessageProvider" ref="jamwikiErrorMessageProvider" />
	</b:bean>

	<!--
	The entry point is the page to which users are redirected when login is required.
	-->
	<b:bean id="authenticationEntryPoint" class="org.jamwiki.authentication.JAMWikiAuthenticationProcessingFilterEntryPoint">
		<!-- do not include virtual wiki in the url, JAMWikiAuthenticationProcessingFilterEntryPoint adds it -->
		<b:property name="loginFormUrl" value="/Special:Login" />
		<!-- a PortMapper has to be configured if this is true and we are not using default ports -->
		<b:property name="forceHttps" value="false" />
		<b:property name="errorMessageProvider" ref="jamwikiErrorMessageProvider" />
	</b:bean>

	<!--
	This filter is executed after the user has been authenticated.  It performs two functions:
	
	1. For users authenticated by LDAP or another system, this filter will create the necessary
	   JAMWiki user database records automatically.
	2. If anonymous users are allowed then this filter will automatically add the roles from the
	   JAMWiki GROUP_ANONYMOUS group.  These roles can be configured through the Special:Roles
	   admin page.  Set the useJAMWikiAnonymousRoles property to false if JAMWiki anonymous
	   roles should not be assigned.
	-->
	<b:bean id="jamwikiPostAuthenticationFilter" class="org.jamwiki.authentication.JAMWikiPostAuthenticationFilter">
		<b:property name="key" value="jam35Wiki" />
		<b:property name="useJAMWikiAnonymousRoles" value="true" />
	</b:bean>

        <!--
        Standard Spring Security integration with EhCache is available to implement object caching.
        -->
	<!--
        <b:bean id="userCache" class="org.springframework.security.providers.dao.cache.EhCacheBasedUserCache">
                <b:property name="cache" ref="userCacheBackend" />
        </b:bean>
        <b:bean id="userCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
                <b:property name="cacheManager" ref="cacheManager" />
                <b:property name="cacheName" value="userCache" />
        </b:bean>
        <b:bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" />
	-->
</b:beans>

As tomcat is still not reporting any valuable error messages (except:

SEVERE: Error listenerStart

So I have tried to debug tomcat and found following error:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices#0': Initialization of bean failed; nested exception is org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [org.springframework.security.web.authentication.preauth.header.RequestHeaderAuthenticationFilter] for bean with name 'siteminderFilter' defined in ServletContext resource [/WEB-INF/applicationContext-security.xml]; nested exception is java.lang.ClassNotFoundException: org.springframework.security.web.authentication.preauth.header.RequestHeaderAuthenticationFilter


I looked out for org.springframework.security.web.authentication.preauth.header.RequestHeaderAuthenticationFilter and found it in:

strings jamwiki-0.9.3/WEB-INF/lib/spring-security-web-3.0.2.RELEASE.jar  |grep RequestHeaderAuthenticationFilter
org/springframework/security/web/authentication/preauth/RequestHeaderAuthenticationFilter.class
org/springframework/security/web/authentication/preauth/RequestHeaderAuthenticationFilter.classPK

I have no clue what to do next, so I hope someone has a good idea.

Your example more-or-less follows the Spring Security documentation for integrating with SiteMinder (http://static.springsource.org/spring-security/site/docs/3.0.x/reference/preauth.html), so I assume that the issue may lie elsewhere. If I search for org.springframework.security.web.authentication.preauth.header.RequestHeaderAuthenticationFilter in the Spring Javadoc I'm not finding anything, although there is a org.springframework.security.web.authentication.preauth.RequestHeaderAuthenticationFilter class - if you update that config do things work? -- Ryan • (comments) • 25-Oct-2010 20:13 PDT
Thanks! That was the issue. I haven't seen that the Spring Security documentation was broken that point. Changing org.springframework.security.web.authentication.preauth.RequestHeaderAuthenticationFilter to org.springframework.security.web.authentication.preauth.header.RequestHeaderAuthenticationFilter brings up the application again.
Well, I still can't see the users which should be reflected by SM_USER in the http headers, but it is a step forward.

[Edit]LDAP auth succeeds and then fails

Archived from the Feedback page:

I'm trying to set up LDAP auth with groups/permissions in the database, but I cannot log in. I can see that JAMWiki successfully authenticates against LDAP in LDAP's log, as if I enter an invalid password, LDAP log contains an error. JAMWiki's debug log contains this:

15:13:03,293 [qtp302785728-237] DEBUG o.s.s.l.SpringSecurityLdapTemplate - Searching for entry in under DN '', base = 'ou=users,dc=stickfish,dc=net', filter = 'cn={0}'
15:13:03,293 [qtp302785728-237] DEBUG o.s.s.l.SpringSecurityLdapTemplate - Found DN: cn=eleonora,ou=users,dc=stickfish,dc=net
15:13:03,294 [qtp302785728-237] DEBUG o.s.s.l.a.BindAuthenticator - Attempting to bind as cn=eleonora,ou=users,dc=stickfish,dc=net
15:13:03,295 [qtp302785728-237] DEBUG o.s.l.c.s.AbstractContextSource - Got Ldap context on server 'ldap://127.0.0.1:389'
15:13:03,297 [qtp302785728-237] DEBUG o.s.jdbc.datasource.DataSourceUtils - Fetching JDBC Connection from DataSource
15:13:03,297 [qtp302785728-237] DEBUG o.s.j.d.LazyConnectionDataSourceProxy - Connecting to database for operation 'prepareStatement'
15:13:03,300 [qtp302785728-237] DEBUG o.s.jdbc.datasource.DataSourceUtils - Returning JDBC Connection to DataSource
15:13:03,300 [qtp302785728-237] DEBUG o.s.j.d.LazyConnectionDataSourceProxy - Using existing database connection for operation 'close'
15:13:03,301 [qtp302785728-237] DEBUG o.j.a.JAMWikiAuthenticationProcessingFilter - Authentication request failed: org.springframework.security.authentication.BadCredentialsException: Bad credentials
15:13:03,301 [qtp302785728-237] DEBUG o.j.a.JAMWikiAuthenticationProcessingFilter - Updated SecurityContextHolder to contain null Authentication
15:13:03,301 [qtp302785728-237] DEBUG o.j.a.JAMWikiAuthenticationProcessingFilter - Delegating to authentication failure handlerorg.jamwiki.authentication.JAMWikiAuthenticationFailureHandler@1f20786c
15:13:03,301 [qtp302785728-237] DEBUG o.s.s.w.a.r.TokenBasedRememberMeServices - Interactive login attempt was unsuccessful.

You can see my config file at http://pastebin.com/2Pz5YJSz Any suggestions?

I don't use LDAP regularly so I'll need to take a closer look at the above after work today. One question - what JAMWiki version are you using? Is this 0.9.x, 1.0.x or 1.1? -- Ryan • (comments) • 25-Aug-2011 09:54 PDT
It's 1.0.1. I didn't see any related fixes in newer versions, so I haven't updated yet. Thanks! One more edit: it's worth noting that LDAP login succeeds if the user already exists in jamwiki's DB from before switching to LDAP.
First, a disclaimer: I've never actually tried the configuration where roles are retrieved from JAMWiki rather than LDAP, but the current example is based on a submission (above) from someone who got it working.
With that disclaimer out of the way, the Spring docs go into a lot more detail on the subject of LDAP configuration and might be worth looking at. Also, when you say your LDAP logs show a failed authentication attempt, but it works when using existing JAMWiki user logins, I'd suspect that the JAMWikiDaoImpl authenticator is still being invoked somehow. One possibility would be that you have an old credential cookie from the pre-LDAP setup in your browser - you could try clearing cookies. The other is that this LDAP configuration has some quirk that is specific to the other user's setup, in which case you could try the "Example #1" LDAP setup from the applicationContext-security.xml file and assign roles through LDAP, something that I've tried and can verify works. Not sure if that helps, but after a half hour looking at this I'm not making a lot of headway - sorry! -- Ryan • (comments) • 25-Aug-2011 20:21 PDT

[Edit]Non-Image Files Uploading

Archived from the Feedback page:

Hello Ryan, I'm uploading some non-image files and it's reported as an image. I read an old discussion about that on Feature_Requests#Non-Image_file_upload_naming but it seems that subject was not continued. The file is ok, i can link it, but my problem is that non-image files are not listed in Special:AllPages search using Image namespace or normal search. I can only find the files if I include a description before upload it. Is there an other way to find it? I can only find the file list at Special:FileList -- Felipe Avilis • (comments) •

The naming issue is one that I'd like to address, but I'd appreciate feedback on how best to proceed - Mediawiki switched from "Image" to "File" a long time ago, so that might be the best option for JAMWiki.
Regarding the fact that non-images don't show up in the namespace search on Special:Allpages, that's a bug and I'll look into it. The same thing happens on jamwiki.org - Image:nules3.pdf doesn't show up in Special:AllPages. -- Ryan • (comments) • 25-May-2011 10:24 PDT
I believe the best way is to treat every file as an object of type File. A file is a file, no matter if it's an image, a video, a PDF or an mp3. Who should know what type of file to be loaded is the loader, not the container. You can not open an image with a music player, or hear a song in Photoshop. I believe this is the best way to create tools to open certain file types like mediawiki:Category:Extensions.
revision 3544 should resolve the issue with Special:AllPages. I'll get the change uploaded to jamwiki.org shortly, and it will be included in JAMWiki 1.0.4. -- Ryan • (comments) • 25-May-2011 13:27 PDT

[Edit]Broken Installation

Archived from the Feedback page:

How do I delete jamwiki to restart the installation? I was using Jboss 5.1 with Jamwiki 0.95 and MySQL 5.1 when I created the jamwiki database with the wrong charset. I deleted this database and re-created a database with the right charset after jamwiki was installed. Now there are many errors in jboss logs when requesting the jamwiki url and it seems that something from jamwiki is persisted somewhere. I have deleted the jamwiki cache, I have uninstalled and reinstalled MySQL, and even tried newer versions of jamwiki 1.0 with JBoss 6. When trying jamwiki 1.0, I am still asked to upgrade upon loading the jamwiki context root in my browser. How can I remove the old instance so I can reinstall jamwiki from scratch?

The /WEB-INF/classes/jamwiki.properties file is created during setup. If that file is still present then JAMWiki will attempt to use the database, URL and other parameters specified in it. I suspect that may be the problem you're encountering, and if so just delete that file and restart. -- Ryan • (comments) • 25-Jan-2011 20:51 PST
Thanks for your reply... unfortunately I don't see this file or anything that looks like it on my server, in app server subdirectories or in mysql / it's directories. I installed Jamwiki into Resin and it worked as expected... I think the problem is related to the JBoss app server but still not able to pinpoint the cause.