Item2349: Unable to create new users when passwordManager is set to None and write access to Main web is restricted.

We’ve encountered this bug in the TWiki software. Because we are likely to switch to Foswiki, we are currently testing the Foswiki software. The same bug also exists in the latest release of the Foswiki software (we've only tested version 1.0.7). I’ve reported the following bug at TWiki.org almost two months ago, but I did not receive any reaction until know. We surely appreciate it if you can help us solve this problem. This is the text of the bug report at TWiki.org:

“We are using TWiki for both our internal and external Wiki servers. During our last upgrade we decided to restrict access to the Main web, by only allowing TWikiRegistrationAgent to make changes to the Main web. This seemed to work great for our external TWiki server. But for our internal TWiki server we make use of SPNEGO to enable the users to make use of the “Integrated Windows Authentication”. Therefore we had to set the passwordManager on None in the TWiki configuration. This always worked fine. During our last upgrade of the Internal TWiki server we also restricted the write access to the Main web in the same way we had done this for our external TWiki server. But from now on users are unable to register properly. Although their user account is created and added to TWikiUsers topic, they don’t receive an email and they are getting the following error message: Access check on TWikiRegistration failed. Action "CHANGE": access not allowed on web.

The owner of the new TWiki user account stays on BaseUserMapping _222. I’ve tried to reproduce this problem with a new clean installation of the TWiki software. I found out that as soon as I set passwordManager to None and when write access to the Main web is restricted, we are receiving the same error message. I also found out the following during this test:

1. When PasswordManager is set to None OR to HtPasswdUser and write access to Main web is NOT restricted -> The new registered TWiki user account will have two revision. The first revision is created by TWikiRegistrationAgent and the second by the just registered user.
2. When PasswordManager = HtPasswdUser and write access to Main web is restricted -> The new registered user account will have only one revisions which is created by TWikiRegistrationAgent.
3. When PasswordManager = None and write access to Main web is restricted -> The new registered user account will have one revision which is created by BaseUserMapping_222 (which seems to be the TWikiRegistrationAgent user). Then TWiki seems to try to create the second revision by using the just registered owner. I think this is where the problem is located, because the only account allowed to edit the Main web is TWikiRegistrationAgent.

So if I’m understanding this correctly: It seems that although the second implementation of registration must be used (Because Main Web is restricted for writing), but when passwordManager is set to None it tries to register using the first implementation. Is this a bug in the TWiki software or does someone know how to solve this problem?

Thank you in advance!

I forgot to mention there is no error message in either the logging of apache nor in the logging of TWiki.”

Thank you in advance for your help!

-- NathanSanders

Unfortunately I can't help with the bug, but I may have a work around...

In System.NewUserTemplate, ensure that you have the following line (the bullet is broken to ensure it does not affect this topic):

   Set ALLOWTOPICCHANGE = %WIKIUSERNAME%

This should overwrite the setting in Main.WebPreferences, allowing the user to have change access on their own topic.

-- AndrewJones - 11 Nov 2009

I'm not sure what is causing what you are seeing, but I just tested that configuration (Main CHANGE restricted to RegistrationAgent, PasswordManager set to none, templateLogin, TopucUserMapping) on trunk and Release01x00. On trunk it works fine - the user is registered cleanly. On Release01x00, it drops into a login prompt before the registration process is complete - I presume because of the access check failure mentioned above.

So, it looks like this is fixed on trunk, but it requires independent verification.

-- CrawfordCurrie - 13 Nov 2009

Thank you both for your quick response!

Andrew: I forgot to mention that I already had implemented the ALLOWTOPICCHANGE = guest in the NewUserTemplate topic, because otherwise indeed the user will be unable to change his/her own topic.

Crawford: I also forgot to mention that we have to use ApacheLogin as LoginManager instead of TemplateLogin. Because we make use of Kerberos Login we have to use the combination: ApacheLogin, PasswordManager set to ‘none’ and AllowLoginName = true. This combination and restricting access to the Main web is causing the problem.

-- NathanSanders - 16 Nov 2009

lets see if i can find this issue in time for 1.0.8 :/

-- SvenDowideit - 25 Nov 2009

1. WebPreferences - * Set ALLOWWEBCHANGE = RegistrationAgent
2. uncomment ALLOWTOPICCHANGE = %USERNAME% from System/NewUserTemplate
3. ApacheLogin, AllowLoginName and PasswordManager=none in configure
4. set require valid-user for standard scripts in apache.conf, and restart apache
5. add a new login name to my htpasswd file
6. delete the session files from foswiki/working/tmp
7. register user TADA it is reproduced.

there we go - now to figure out why :/

OMG

I didn't read the NewUserTemplate, I just edited it to remove the '#' in the Set line.

thats quite useless - then when I moved it to where it needs to be (above the %STARTSECTION{type="templateonly"}% section, registration works for me.

thus setting this Item back to Nathan, and I'm sending him an email.

---

I get exactly the issue you report if I don't move the ALLOWTOPICCHANGE before the STARTSECTION (which is removed when the new user topic is created)

to confirm - make sure that the user topic that is created actually contains

Set ALLOWTOPICCHANGE=Main.TheUsersWikiName

(three spaces, star, then a space)

-- SvenDowideit - 25 Nov 2009

(from an email from Nathan:)

Dear Sven,

thank you for your help. I made the same mistake with the configuration of Foswiki. Although I've better tested this bug/problem in the TWiki installation, I only executed one test for the Foswiki. I must have mist that the ALLOWTOPICCHANGE was not outside the %STARTSECTION section. Today my colleague and I made a fresh installation of both TWiki and Foswiki. The bug only seems to exist in TWiki. Thank you all for your help!

PS: I'm unable to add this comment to the bug report, because of the setting " * Set ALLOWTOPICCHANGE=Main.TheUsersWikiName" in the text of the bug report.

With Kind Regards, Nathan Sanders

And so I regrade this as a docco / obfuscated topic issue not a release blocker, but it sure would be nice not to leave trip mines for our users.

-- SvenDowideit - 29 Nov 2009

Is this still an issue? The NewUserTemplate doesn't contain the referenced STARTSECTION type=templateonly.

-- GeorgeClark - 07 Mar 2012

This is indeed no longer an issue in the newest version of Foswiki.

-- NathanSanders - 20 Apr 2012