Hello,
Sometimes the problem comes up that an external tool needs to verify whether a user is the same user as on a wiki. For example one may want an opt-in system for an editcounter [1]. Or you are organizing a competition in which every Wikimedian can vote [2]. Currently such authentication is done with various hacks, such as posting some code in an edit summary, abusing the mail features of mediawiki or having the user post a certain token to a wiki page. This is not ideal and moreover quite complicated for the non tech savvy people.
I would therefore like to have some way to verify a users identity without asking his password or posting some weird stuff to some page. What I think would be a solution: # The user visits http://externaltool.com/authenticate and submits his username (and wiki). # The tool will add the user to its database, generate some random token and redirects the user to http://wiki.org/wiki/Special:VerifyUser?token=secret # MediaWiki will then check whether the user is logged in and if not ask to login. # MediaWiki will do some magic and generate a new_token from token and redirect the user back to the tool, adding the new_token to its url # The tool will then query the wiki with its token and the new_token and ask whether the two tokens form a valid pair
The downside of this would be that there are many redirects involved and also quite a lot of traffic. Would such a thing have any chance of being enabled on Wikimedia wikis if developed?
Cheers, Bryan
* [1] http://tools.wikimedia.de/~interiot/cgi-bin/editcount_optin.cgi?user=Commons... / http://tools.wikimedia.de/~interiot/cgi-bin/editcount_optin.cgi?user=Commons... * [2] http://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2007/Voting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bryan Tong Minh wrote:
Sometimes the problem comes up that an external tool needs to verify whether a user is the same user as on a wiki. For example one may want an opt-in system for an editcounter [1]. Or you are organizing a competition in which every Wikimedian can vote [2]. Currently such authentication is done with various hacks, such as posting some code in an edit summary, abusing the mail features of mediawiki or having the user post a certain token to a wiki page. This is not ideal and moreover quite complicated for the non tech savvy people.
I imagine this would be fixed with SUL (Singer User Login)
On 1/21/08, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bryan Tong Minh wrote:
Sometimes the problem comes up that an external tool needs to verify whether a user is the same user as on a wiki. moreover quite complicated for the non tech savvy people.
I imagine this would be fixed with SUL (Singer User Login)
Um, how?
On Jan 20, 2008 8:20 PM, Andrew Garrett andrew@epstone.net wrote:
On 1/21/08, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bryan Tong Minh wrote:
Sometimes the problem comes up that an external tool needs to verify whether a user is the same user as on a wiki. moreover quite complicated for the non tech savvy people.
I imagine this would be fixed with SUL (Singer User Login)
Um, how?
-- Andrew Garrett
With SUL, your user account name would be global. If you had the username on one wiki, you would have it by default on all the other wikis as well. Proving that you were the same person on both wikis would be as simple as showing that the account existed in both places.
--Andrew Whitworth
On 21/01/2008, Andrew Whitworth wknight8111@gmail.com wrote:
On Jan 20, 2008 8:20 PM, Andrew Garrett andrew@epstone.net wrote:
On 1/21/08, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bryan Tong Minh wrote:
Sometimes the problem comes up that an external tool needs to verify whether a user is the same user as on a wiki. moreover quite complicated for the non tech savvy people.
I imagine this would be fixed with SUL (Singer User Login)
Um, how?
With SUL, your user account name would be global. If you had the username on one wiki, you would have it by default on all the other wikis as well. Proving that you were the same person on both wikis would be as simple as showing that the account existed in both places.
That won't help with external (ie toolserver-based) tools at all, though.
Brianna
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Edward Z. Yang wrote:
I imagine this would be fixed with SUL (*Singer* User Login)
Haha, I suppose the feature would only apply to vocal people... SINGLE user login is what I meant.
Bryan Tong Minh wrote:
Sometimes the problem comes up that an external tool needs to verify whether a user is the same user as on a wiki. For example one may want an opt-in system for an editcounter [1]. Or you are organizing a competition in which every Wikimedian can vote [2]. Currently such authentication is done with various hacks, such as posting some code in an edit summary, abusing the mail features of mediawiki or having the user post a certain token to a wiki page. This is not ideal and moreover quite complicated for the non tech savvy people.
Sounds like a job for OpenID...
It's on the agenda (Evan's been maintaining an extension, though we haven't taken it on yet).
-- brion vibber (brion @ wikimedia.org)
On Jan 21, 2008 8:30 AM, Brion Vibber brion@wikimedia.org wrote:
Sounds like a job for OpenID...
It's on the agenda (Evan's been maintaining an extension, though we haven't taken it on yet).
-- brion vibber (brion @ wikimedia.org)
Is there some time estimation for that? Like before or after SUL? :)
Bryan
As a stop-gap measure, how about this: * New tool on toolserver * Centrally manages verified combinations of wikipedia user names and openid * Verification through one (any) of the existing "hacks" * Answers queries like "is openid X the user Y on wikipedia Z" for other tools
Advantages: * Avoids duplication of verification * Available for all tools ("toolserver single signon";-)
Disadvantages * Still uses hacks * Tools still have to verify openid
Too much trouble to go through?
Magnus
On Jan 21, 2008 10:54 AM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On Jan 21, 2008 8:30 AM, Brion Vibber brion@wikimedia.org wrote:
Sounds like a job for OpenID...
It's on the agenda (Evan's been maintaining an extension, though we haven't taken it on yet).
-- brion vibber (brion @ wikimedia.org)
Is there some time estimation for that? Like before or after SUL? :)
Bryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Jan 21, 2008 2:37 PM, Magnus Manske magnusmanske@googlemail.com wrote:
Too much trouble to go through?
Magnus
Well, it is still much better than the current situation. However my proposal concerns mostly the third point 'Verification through one (any) of the existing "hacks"'. Ideally we would have a centrally managed user system that uses my previously proposed system or some other clean system.
Bryan
Developing something new to make this work while something is readily available sounds quite evil to me (re-inventing the wheel, anyone?). A consideration is that in case this is actually going to be developed, we (Wikimedia) will possibly never be able to get rid of it because it'll have its tentacles deep into all kinds of stuff as a more widely available solution becomes available.
Let's not rush into this and think about using readily available (and possibly proven) solitions. OpenID could be one. Having SUL would probably make it easier to tie that all to Wikimedia wiki accounts...
Cheers! Siebrand
-----Oorspronkelijk bericht----- Van: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Namens Bryan Tong Minh Verzonden: maandag 21 januari 2008 15:48 Aan: Wikimedia developers Onderwerp: Re: [Wikitech-l] Verification of identity for external tool
On Jan 21, 2008 2:37 PM, Magnus Manske magnusmanske@googlemail.com wrote:
Too much trouble to go through?
Magnus
Well, it is still much better than the current situation. However my proposal concerns mostly the third point 'Verification through one (any) of the existing "hacks"'. Ideally we would have a centrally managed user system that uses my previously proposed system or some other clean system.
Bryan
Bryan Tong Minh wrote:
On Jan 21, 2008 8:30 AM, Brion Vibber brion@wikimedia.org wrote:
Sounds like a job for OpenID...
It's on the agenda (Evan's been maintaining an extension, though we haven't taken it on yet).
-- brion vibber (brion @ wikimedia.org)
Is there some time estimation for that? Like before or after SUL? :)
Setting up an OpenID provider could be done entirely unrelated to SUL.
-- brion vibber (brion @ wikimedia.org)
On Jan 20, 2008 11:30 PM, Brion Vibber brion@wikimedia.org wrote:
Sounds like a job for OpenID...
It's on the agenda (Evan's been maintaining an extension, though we haven't taken it on yet).
Agreed, this is really just what OpenID was conceived for. No point in reinventing the wheel.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brion Vibber wrote:
Sounds like a job for OpenID...
Would this mean that Wikimedia would become an OpenID provider?
On Jan 21, 2008 6:16 PM, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
Brion Vibber wrote:
Sounds like a job for OpenID...
Would this mean that Wikimedia would become an OpenID provider?
Yes, and optionally a relying party as well.
On 22/01/2008, Edward Z. Yang edwardzyang@thewritingpot.com wrote:
Brion Vibber wrote:
Sounds like a job for OpenID...
Would this mean that Wikimedia would become an OpenID provider?
Sounds like a good and useful idea to me. "Oh, you're that guy from Wikipedia." People should be able to edit with the attribution being to an OpenID.
- d.
On Jan 22, 2008 12:27 AM, David Gerard dgerard@gmail.com wrote:
Sounds like a good and useful idea to me. "Oh, you're that guy from Wikipedia." People should be able to edit with the attribution being to an OpenID.
Well, maybe. At the very least, we should require a captcha for OpenID signups. Then they're not really any different, abuse-wise, from any signup (if you can write a script to auto-generate OpenIDs you can definitely write a script to auto-fill the username and password fields). We'd also want to require independent validation of the e-mail address, if the user provides one, unless the provider is trusted.
However, creating an OpenID account should be very easy, I think. Have a captcha and maybe a form for e-mail address. Although I guess we'd still have it in the usual place, and not (for instance) at the top of every edit page, since we don't seem to encourage signing up *too* much . . . why did we get rid of the old combined signup/login form again? tomgilder removed it in r11896 with no particular explanation. I rather liked it, it made MediaWiki signup far and away the easiest of any web software I had ever used. Now there's an extra click required.
On Jan 22, 2008 5:56 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Jan 22, 2008 12:27 AM, David Gerard dgerard@gmail.com wrote:
Sounds like a good and useful idea to me. "Oh, you're that guy from Wikipedia." People should be able to edit with the attribution being to an OpenID.
Well, maybe. At the very least, we should require a captcha for OpenID signups. Then they're not really any different, abuse-wise, from any signup (if you can write a script to auto-generate OpenIDs you can definitely write a script to auto-fill the username and password fields). We'd also want to require independent validation of the e-mail address, if the user provides one, unless the provider is trusted.
I'm not sure whether I understand OpenId's concept well enough, but what if Wikimedia would only be an OpenID provider? This way one can use their Wikimedia account on other places on the net, without having us to worry about the trustworthiness of other providers.
Bryan
On Jan 22, 2008 9:18 AM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
I'm not sure whether I understand OpenId's concept well enough, but what if Wikimedia would only be an OpenID provider? This way one can use their Wikimedia account on other places on the net, without having us to worry about the trustworthiness of other providers.
Of course we could do that, and it would solve the original issue. But I don't see a good reason to stop there (except, perhaps, that it would be easier, but we already have a perfectly good OpenID extension, don't we?).
wikitech-l@lists.wikimedia.org