Comments:Configuration

1 Virtual Wikis 1.1 Remove Virtual Wikis 2 How can i change the background of the stylesheet? 3 adding navigation entry 4 Is there a way to use classic mediawiki search instead of lucene? 5 Images 5.1 Remove Image 6 CSS Question 7 Time format (again...) 8 DATASOURCE_README.txt 9 Rename default virtual wiki 10 Using permissions to hide pages 11 LDAP Setup 12 User Defined Roles 13 MySQL Timestamp error 14 Admin Add/Create User 15 How Can I Reset the Administrative Password? 16 Removing the self registration 17 Upload folder outside of WAR 18 Preventing search 19 Single Sign On 19.1 Single Sign On without going Whole Hog 20 LDAP Users with '-' in user name can't login anymore

[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 ans 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. --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