Moved from ImproveTestenv - the idea is a script like testenv that focuses on the SecureSetup of TWiki, and in particular on whether the user data in TWiki is synchronised with the .htpasswd setup.

I have somewhat changed the focus of the initial request here, because I think it would be useful to test this on a continuing basis, using a suitably password-protected script of course! SecureSetup testing could also do other checks perhaps.

-- RichardDonkin - 15 May 2003

Check User Data Consistency

To register a User they need a Main.WikiName as well as an entry on the Users page. They may also need an entry in .htpasswd if htaccess is being used, so it is very easy for these separate sources of data to become unsynchronised. Flagging this up would be useful. Providing tools to correct it would help as well, for DeletingUsers? for example.

Also, if htpasswd is being used, then the accounts which are only example accounts shipped with the distribution should be flagged up as being there, otherwise there is a backdoor entry into the system for those who have figured out the password(s). (Not every TWiki is intended to be open to the world.)

-- HughSasse - 14 MAY 2003

This sounds like a separate tool, perhaps linked from testenv or from a documentation page. The built-in accounts should just be disabled as part of the build process (by shipping an empty .htpasswd perhaps) - has been logged as a bug but not fixed yet.

-- RichardDonkin - 14 May 2003

Hugh, testenv helps with initial installation. Your tool, testusers, could rely on fully functioning Twiki (if you want to code it).

-- PeterMasiar - 14 May 2003

GreenHat? : It's not just initial installation though: testenv checks the config, and the apache server to some extent ("Warning: This does not match HTTP_HOST"), and an insecure setup is just as broken as other cases that are tested. I believe that the present design violates "DRY -- Don't Repeat Yourself: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." (http://www.pragmaticprogrammer.com/ppbook/index.shtml), and the diagnostics from register don't say which file has missing data. DRY is also a case for putting all the testing code in the same test harness (testenv in this case): the testing knowledge is not in two separate places. (As to fixing the code, I have spent some time looking at this, but I'm not familiar enough with the code base and am not really fluent in Perl5 to make this achievable in realistic time for me. Are there any docs on the internal organization of the code that would speed up the learning curve?) Can this be moved from outright rejection to low priority?

-- HughSasse - 15 May 2003

Modularising testenv would be good since it's already quite long - can be linked from testenv of course, but should probably be password protected.

-- RichardDonkin - 15 May 2003

Password protecting it is a good point: it "spills the beans" to some extent on your apache setup, for example.

-- HughSasse - 15 May 2003