Ok, after poking around, the web server auth option works fine as a IIS
Integrated solution, however it is too literal. It expects the username
to match exactly what is in the tiki db (obviously). Add to that the
fact that the "\" in the domain\username string is escaped ("\\") and it
doesn't conform to what windows admins are used to. IIS Integrated
login will always send the domain name across in REMOTE_USER, so no
chance of changing the passed in username from the server's side.
Since I don't want to set up my usernames as "Domain\\Username" for each
user, and deal with the ugliness on all my pages (edited by
"Domain\\Username") I added some logic to the setup-base.php to try
three things on a web server based login:
1. String for string match
2. Domain\Username with just one slash (for admins with multiple domains
who want to include the domain in their logins)
3. Just the Username.
It does these in order, so the more paranoid admin can set up users
however he likes, and Tiki compensates. The only real issue I see is
that as soon as the webserver login is set - the admin can no longer log
in directly. However, I seem to remember there is a manual login back
door - does that still exist and where?
I also have a patch to tiki-setup.php to compensate for IIS servers.
Line 44 has to be changed every time because the IIS server isn't giving
PHP the SCRIPT_FILENAME variable. I wasn't sure if the PATH_TRANSLATED
variable existed under Linux, so I added an IF on the web server type
and chose a different path depending upon whether it was IIS. Its a
ugly hack, so if PATH_TRANSLATED can be used under apache, I move we
change the docroot to use that.
These are my first patches, both in Tiki and with CVS, so I want another
set of eyes on it before I commit the changes. I've attached the patch
file so let me know if it doesn't conform with tiki standards, or if
there are better string functions to use - I'm still new to PHP too. :)