So, may I propose that we factor out from the register.pl script the calls to Apache?

As a first step, the routines:

• htpasswdGeneratePassword
• htpasswdExistUser
• htpasswdAddUser

could to be moved to lib/TWiki/Apache.pm

Then have a base class UserList as an interface with routines:

• addUser
• userExists

And have generatePassword internal to Apache.pm

Then have both IIS.pm and Apache.pm implement UserList.pm and have register.pl use only the interface in UserList.pm and TWiki.cfg select whether we use IIS.pm or Apache.pm.

M.

-- MartinCleaver - 30 Oct 2001

Martin,

Ahhh...so that's the problem with setting up authentication with IIS! Have you implemented this?! Would really appreciate any pointers you could give me to get around the problem!

Thanks,

David

-- DavidHay - 30 Nov 2001

I'm just starting to get TWiki running on IIS right now, and one of the things I've already done is to comment out everything in register.pl that referred to htpasswd. That file does absolutely nothing if you're using IIS, and the only thing TWiki does with it is add and modify entries in it, presumably for the benefit of the non-existent apache. (I also commented out the "use Digest::SHA1" line, since for some reason that module isn't included in my installation, which is an older ActiveState build).

There are probably many ways to make authentication work using IIS and Windows, but here's what I've done so far. The assumption I'm working from is that you have all of your potential users already set up with Windows authentication, either as local users on the server or as users in a domain that the server can authenticate against. Given all that:

The first thing I tried was to restrict access to the TWiki directories using Windows ACLs. This didn't work as I had hoped. The scripts would run without any requests for username/password in the browser, but the scripts would fail with "The CGI application returned a bad set of headers", and the headers returned were "view.pl : access denied" or some such. The reason is that when the browser requests the script URL, IIS tries to run perl.exe as a CGI. When running the CGI it does a user context switch to the IWAM user. The IWAM user has permissions to run perl.exe (at least, it does on my system), so from IIS's perspective the CGI succeeds. But then perl.exe tries to open view.pl using the IWAM user context, and with the restrictive ACLs on the TWiki directory that attempt fails. But since IIS thinks the CGI call succeeded (since perl.exe ran successfully albeit returning invalid HTML headers), IIS won't request any additional username/password credentials from the browser.

So that didn't work. Next I set the ACLs on the TWiki directory so that Everyone had read/execute access (it would probably suffice to give the IWAM user read/execute access instead of Everyone). Then, in the IIS Control Panel (the "Internet Information Services" applet under "Administrative Tools" in Windows 2000) I disabled anonymous access (web site -> properties -> Directory Security -> Anonymous access and authentication control -> Edit -> Anonymous Access checkbox). I also checked "Basic authentication" and "Integrated Windows authentication".

This seems to work rather well for what I want to do, although I'll keep playing with it for the next few days. It requires anyone who wants to access the TWiki at all to have a valid username and password in the Windows domain, and the TWiki gets the username correctly. Registration works correctly, and while it doesn't do anything to the (useless) htpasswd file, it still sets up the right entries in the TWikiUsers topic and creates the users' topics under Main.

Hope this helps. This should probably all go in the TWikiOnWindows topic, but I'll have more to say there once I get more done on the actual installation.

-- TWikiGuest - 08 Dec 2001