If there's really a need for opt-in, I think that the toolserver should provide a better method for authenticating users. Since most tools can't access user's passwords, maybe root should provide a single page where users can enter their site + username + password, and a cookie could be set, and it would redirect back to the original toolserver tool, and any toolserver tool can read that cookie to confirm the user is who they say they are. In this way, it would be much easier for any tool to implment an opt-in / opt-back-out mechanism, and it would be more user-friendly for end users as well.

There are also tools that would be useful to provide to admins or checkuser accounts only, and a central authentication page would allow this to function as well. Currently, if admins want to use my tools to investigate possible sockpuppets or the like, they have to ask the sockpuppet to opt-in first.

I think my current opt-in code is interesting, but it is not a long-term solution. It is too cumbersome for users to opt back out, or to ask for only specific features to be opted-in.

-Dave

On Sun, Aug 06, 2006 at 07:34:12PM +0200, Jakob Voss wrote:

Hi folks,

I just wanted to let you know that we had a meeting of the board of Wikimedia Germany. At least until we have a clear answer from our lawyers we don't want tools that aggregate personal data because of privacy. But opt-in is all-right of course. Maybe you could spread more that there are tools you can opt-in for and that other people cannot get nice stats of what you have done in a Wiki if you don't opt-in.

Greetings, Jakob _______________________________________________ Toolserver-l mailing list Toolserver-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/toolserver-l

On Mon, Aug 07, 2006 at 10:28:01AM +0200, Daniel Kinzler wrote:

interiot@68k.org wrote:

...

If there's really a need for opt-in, I think that the toolserver should provide a better method for authenticating users.

This seems like a perfect application for OpenId http://openid.net/. I haven't read the specs and don't know how exactly it works, but it shouldn't be hard to implement. MediaWiki already has an OpenID extension, see http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/OpenID/

-- Daniel

If OpenID was installed at all wikimedia servers, that would work, and it would avoid replication lag.

If enwiki replication was working though, we wouldn't need anything very complicated... a special database login would have access to the verification information, and most toolserver apps run on a single web domain, so it's straightforward to pass cookies from a central sign-on to all toolserver tools, and we would just need something like asymmetric encyrption to make sure the cookies can't be modified.

-Dave

Shared secret keys, stored on the php files are bad. Specially if the code is being showed to the world. Better use a global file on the include_dir with a generic functions

An example:

<?Php include("toolserver_auth");

if (IsAuthenticated()) echo "Hello " . $Toolserver_User; else { if (PHP_FILE == "help.php") print "You will need to log in to see the other pages. \n They're awesome"; else ToolserverAuthNeeded();

echo "You're an authenticated user. Welcome $Toolserver_User";

?>

The Cookie checking and openid work stays on IsAuthenticated() The cookie can be everything, any hash you want and the shared secret can be changed several times a week without problems. The ToolserverAuthNeeded() function would redirect to / show the correct page to log into. It would end with exit() ,stopping the rest of the file.

Sadly, we may need to wait for the single login to have this tools auth working. But having it before would be nice :)

Interiot, i assume you were thinking in using the hash stored for the users password on mediawiki, but i thought it wasn't replicated, that user info wasn't on toolserver ¿?