Lucifer recommended the ZThread library; apart from two quirks, one solvable, I can pass on that recommendation.
Quirk one is that the installed zthread-config apparently ignores a prefix set in your .site configuration script, which means it will be broken.
Quirk two is that it is leaking a single memory block as soon as you start a thread. Well, not really leaking, probably. According to valgrind, the memory is possibly lost. The custom debugging memory manager reports it as a leak, anyway.
A general problem with multithreading is that it breaks our debug recordings, badly. That's because the debug recording facility relies on the fact that with identical inputs, the program will run the same way again; that assumption breaks down with multithreading.
The http-fetching password check luckily interacts only with two of our systems: the memory manager (easily secured with mutex locks in its main access points) and the tToDo task scheduling system (as soon as the answer from the password server is received, wrapping up the authentication is left to a task called from the main thread and scheduled over tToDo, because that's the easiest way; the alternative would be to make the ePlayerNetID management thread safe). Concurrent password fetches seemed to be no problem.
Everything is optional at compile time. It's possible do enable and disable the krawall authentication alltogether, and without ZThreads, the http based distributed authentication is disabled and only local accounts are available.
So the low level implementation is there and works, let's think about good ways to administer this beast.
For the user, I was thinking about the following chat commands:
/adminlogin <password>: does what /login <password> does now; check ADMIN_PASS and log in.
/login : trigger a krawall login to a local user account or a default password server, depending on what the admin set
/login <password server> : logs in with an account from the given password server.
/logout : log out again.
After you're logged in, your password server or local account type is stored in your ePlayerNetID, and you can appear now as user@<password server> resp. user@local in log files etc. Obviously, we should filter the character @ out of usernames, and refer to unauthenticated users as user@ in the log files, and @local users should be transformed to @local-<servername> users by luke-jr's ranking script.
Now, the commands described in earlier posts are sort of useless. You would want to make an arbitrary user an admin or moderator without forcing him to use a local account, messing up his ranking. You'd want so simply declare that
z-man@moosnet.homelinux.net is an admin, for example with the command
as simple as that. Same for team leaders. What I'm getting at here is that admin, moderator and team leader properties should sit on top of authentication, and not be built into it like in the published version of the patch.
For non-leader team members, we can keep the stuff that's in the first patch; the /pickup chat commnand for team leaders and the local team password, because both may be convenient for certain situations, and also add support for team list fetching over http or from files. So, for example, once everyone has done their homework and an SP vs oops match is scheduled on a server, the admin only should have to add
Code: Select all
ALLOW_TEAM CT@crazy-tronners.com
ALLOW_TEAM oops@armagetronad.net
to the configuration and be set. For clan wars and ladles, that would be the way to go; for AFL like things, the team lists should be fetched from the organizer to avoid teams switching members while they're not allowed to.
I don't think we should go down the road to allow clans and teams to authenticate their members for other purposes than organized matches. I don't want to be drawn into "X is not allowed to wear clan tag Y" debates.
The "who is allowed to play" logic needs a little reworking, too, of course. We want to differentiate
* nonauthenticated players
* authenticated players
* members of teams that are scheduled to play
A server where the ranking script is supposed to give meaningful results could, for example, simply enforce authentication. A tournament server would only let scheduled teams play. There should always be the additional option that if nobody of the required level is online, members of lower level can play anyway.
The current password server test script looks like this:
Code: Select all
<?php
$user = @$_GET[ "user" ] . '';
$salt = @$_GET[ "salt" ] . '';
$hash = @$_GET[ "hash" ] . '';
// check whether user is in "database"
if ( $user != "test" && $user != "test2" )
{
echo "UNKNOWN_USER " . $user . ".";
}
else
{
// simulate delay
sleep(10);
// fetch password hash from "database"
$password = md5("test" . pack("H*", "00" ) );
$packedSalt = @pack("H*", $salt );
$packedPassword = @pack("H*", $password );
$correctHash = md5( $packedPassword . $packedSalt );
if ( $hash == $correctHash )
{
echo "PASSWORD_OK";
}
else
{
echo "PASSWORD_FAIL "; // . $correctHash . " " . $password;
}
}
?>
The password md5, as the client computes it, includes the trailing 0. That means there is no way to compare it to, say, a stored password md5 of phpBB. To support that, and the other shemes where the first step is not to simply take a password md5, we'd need to change the protocol and send strings to the client it should prepend and append to the password before doing the initial md5 sum. That would give us support for phpBB and htdigest files and Lucifer's prepend-password-with-servername suggestion.