API talk:Login

Login / lg
How is the password verified by the server? How is the password sent? Plaintext / encrypted? What encryption is used?

Perhaps someone more knowledgable can fill in this table: Thanks a lot in advance, Shinobu 04:49, 20 December 2006 (UTC)


 * From what I can tell, HTTPS is not supported. Also, since the authentication is form-based, the only option for sending the password is plain text. Using status code 401, HTTP itself supports Basic and Digest authentication as standard schemes, although Digest is not used all that often. In the case of Basic, it is effectively plain text; for Digest, it is an MD5 digest of the password, so it is effectively encrypted. All of this is moot because MediaWiki doesn't do this.


 * The problem is that if anything but plaintext is received by the server, you are limited in how the passwords can be stored in the database. For instance, if you use digest authentication based on MD5, the version of the password has to be based on the MD5 hash of the password, since it can't check against another hashing/crypting scheme without reprocessing the original password. In the case of MediaWiki, this would actually work, since it's database value is based on an MD5 hash of the plain text, but I'm not sure that there is consistent browser support for Digest authentication. The other issue is that using form-based authentication allows you to have a pretty HTML form for posting and let's you implement stuff like "Remember me", since HTTP authentication doesn't support this (regardless of whether you use Basic or Digest). Hope that helps. Mike Dillon 16:38, 22 December 2006 (UTC)


 * What I said about Digest authentication is a little inaccurate; since it isn't relevant to what MediaWiki does, you can just ignore my correction if you aren't interested.


 * The real problem is that without access to a plaintext versions of the password on the server, the server can't reproduce the expected response in the challenge/response protocol. This is because the response is based on the MD5 hash of not just the password, but other information as well. Since MediaWiki only stores the MD5 hash of the password, it can't generate the expected hash when the other components of the HA1 hash are factored in (see Digest authentication for more details).


 * There are further complications if MediaWiki has been configured with the  setting, since it actually double-hashes to get the value that's stored in the database in that case. Since MD5 is a one-way hash, there is no way for the server to get back to the original password. All it can do is verify that what the user sent as the password can be re-hashed to the same value. Mike Dillon 04:42, 24 December 2006 (UTC)

So in summary, the password is always sent in plaintext?

@From what I can tell, HTTPS is not supported: I think https is supported: Main Page (https), so I should think that only URLs are passed unencrypted, right? POST data and responses should be encrypted. Unfortunately, it doesn't seem to know that I already signed in on http, so apparently when you use the https login you have to do everything in https. Question is, is API supported using https?

@form-based, the only option for sending the password is plain text: One could calculate the MD5 hash using JavaScript, or one could use https. Considering I've already sent my password in plaintext, it should at least be possible to verify and/or change it without doing so again. Sending the password in plaintext again and again seems even less wise than doing it once.

I'm pretty new at this, but sending passwords in plaintext seems pretty dumb to a layman. Not warning about it even more so. Shinobu 08:03, 24 December 2006 (UTC)


 * I didn't know about secure.wikimedia.org. I'm not sure that you can log in to that server and get a cookie that will work on a non HTTP version, though. I just tried to use: https://secure.wikimedia.org/wikipedia/en/w/api.php?action=login&format=xml&lgname=Username&lgpassword=Password&lgdomain=en.wikipedia.org and I got a cookie in "secure.wikimedia.org", which means that all traffic must go through that domain instead of en.wikipedia.org. Also, since the server sets the "secure" flag on the cookie, normal HTTP libraries won't send it to the plain HTTP URLs on secure.wikimedia.org, so you have to take the SSL overhead on every request to stay logged in. If you aren't trying to use the cookies returned, you should be able to use the lgtoken value returned in the API response against en.wikipedia.org, but I haven't tested that. I didn't look into what is done on the server side with the login token.


 * As for what is encrypted when using HTTPS, everything is encrypted, including the URL. All that can be seen by sniffing is that you're sending data to the server's IP address using SSL. You can't see any headers or the HTTP request body or URL, since they're part of the SSL payload.


 * Regarding the use of Javascript to send an MD5 hash, it could be done, but the MediaWiki software would have to support it and you'd have to find Javascript code to do the hashing.


 * I'm not sure what you mean about sending the password again and again. It should only be sent to the login action. After that, you either use the cookies returned or the login token in the API response to send what is effectively a session id, not your password. Mike Dillon 20:31, 24 December 2006 (UTC)

Regarding encryption on secure.wikimedia.org, I just saw this post on English Wikipedia's technical village pump. The poster claims that the "null" cipher is possibly being used for the HTTPS server and if so even that is not encrypted... I just checked it and saw "AES 256", so I'm not sure whether it is encrypted or not. The browser said it was AES 256 and the stream looked encrypted in a packet capture, so this is mainly just an FYI. I'm not sure if there is any documentation on the cipher used by the HTTPS server. Mike Dillon 00:23, 27 December 2006 (UTC)


 * There have been some additions to the aforementioned discussion from Brion VIBBER. The null encryption thing is not true, but he mentions some other quirks of the secure.wikimedia.org server. See en:Wikipedia:Village pump (technical). Mike Dillon 15:33, 27 December 2006 (UTC)

@you'd have to find Javascript code to do the hashing: There is a module to do this. w:User:Lupin/md5-2.2alpha.js Although one should be careful about what to hash, because otherwise the hash could be sniffed and used instead, defeating the purpose of sending a hash.

As much as I understand this to be a complicated issue, I still think it needs to be fixed. Shinobu 19:06, 28 December 2006 (UTC)


 * I just tried the following:
 * Log in using API to secure.wikimedia.org
 * Note the lgusername, lgtoken, and lguserid fields in the response
 * Request a watchlist against en.wikipedia.org using those values
 * Unfortunately, I received . As I said before, I haven't looked into how the tokens work to see what the problem might be, but I would think this should work. Of course, at that point your session can be hijacked since you're sending the token over the wire unencrypted, but there's really no way to avoid this except for using SSL for every request. At least nobody can steal your password...


 * I also noticed that I get the same token back for subsequent login requests. Mike Dillon 22:13, 30 December 2006 (UTC)


 * I am also trying to the exact same thing as Mike Dillon said above. I've gone through the same steps with the same lack of result. I'm passing lgusername, lgtoken and lguserid in POST, and verifying this in my app before it goes out. I'm extremely new the API, but trying getting it rapidly except for this hiccup. Any progress here? Eddieroger 05:58, 13 February 2007 (UTC)


 * Hope this helps : Example of the Atom authentification (the only remaining problem is that passwords are kept in clear by the server, but the transaction is secure). I don't know if there is an updated version. w:fr:Leafcat

I hate reopening old issues, but I still can't get login working without using cookies. I am able to login with result code of "success," but when I pass those parameters back in to the API along with my request, I still get wlnotloggedin errors. I'm testing this against en.wikipedia.org as a normal non-bot user. Can anyone confirm that it works at all? Eddieroger 23:16, 4 August 2007 (UTC)


 * Same problem, (In PHP):
 * $wiki = 'http://en.wikipedia.org/';
 * $url = $wiki . 'w/api.php?action=login&lgname='.$username.'&lgpassword='.$password.'&format=xml';
 * $http = http_parse_message(http_get($url))->body; /* Works */
 * $xml = simplexml_load_string($http);
 * $login = "&lgtoken={$xml->login['lgtoken']}&
 * lgusername={$xml->login['lgusername']}&lguserid={$xml->login['lguserid']}";
 * $url = $wiki . 'w/api.php?action=query&list=watchlist' . $login;
 * $watchlist = http_parse_message(http_get($url))->body; /* */
 * Carpetsmoker 06:02, 27 August 2007 (UTC)

It seems I am having the same problem. When trying to issue a recentChanges query using a PHP program, I get very different results than when I log in to a browser and issue the same query from the browser window. It seems there are problems with the login and token passing in the URL query string, but seems to work fine if I use cookies. Formatting cookies in PHP is no where near as easy as formatting a query string :-( 128.221.197.20 14:30, 11 September 2007 (UTC)
 * Try Snoopy, a PHP class that makes this stuff easier. --Catrope 15:05, 11 September 2007 (UTC)
 * I believe the secure and unsecure servers require separate logins.

POST?
Am I getting it right that currently login works only via GET and you have to disclose your login in URL? MaxSem 10:47, 21 November 2007 (UTC)
 * No. Both GET and POST work just fine for all API modules. --Catrope 13:43, 21 November 2007 (UTC)
 * No, certain api modules such as login require that you do a post.

User-Agent
Hello. Since few days iv got problem to connect my robot with the API. Checking the code, i see i receive "Scripts should use an informative User-Agent string with contact information, or they may be IP-blocked without notice.". But the error is not embbeded into XML, then everything crash. Then, is there a way to embbed this message into XML?

My second problem is i dont know what "informative User-Agent string with contact information" mean. I really dont know where i can ask help. Maybe it is outside the topic of the page. I dont know. 82.246.189.168 20:56, 18 February 2010 (UTC)
 * See User-Agent_policy. Tisane 12:04, 6 May 2010 (UTC)

New problem with API:login
Hello, I'm using api.php for a while now for a set of tools around my bots (on fr.wikipedia.org). Today I get a problem to log in (but maybe it exists before, but my token was expired, so I really my program really attempt a login). When I try to log, I get a "NeedToken" reply, with a associated token: I don't understand why, because this part of the code works for mounthes without any problem. I also tried to add lgtoken=faab82e4158d864b9f06304c9cb870ec (in this example) to the POST data (with the lgname and lgpassword) with exactly the same effect: it still replies a "NeedToken" and gives a new "token" value.

Any clues to help me? If it can help this part of the code is an independant script in shell (Linux) using Curl, code that is used for at least 3 mounthes by now.

Regards, Hexasoft 09:57, 9 April 2010 (UTC)
 * Details: login action is performed this way:
 * (-d option is the POSTed data)
 * I also tried passing "lgname=Hexabot&lgpassword=mypassword&lgtoken=the_token_in_previous_reply" without success.
 * Hexasoft 10:02, 9 April 2010 (UTC)


 * Hi, the login procedure has changed a few days ago, and every tool need to be modified to work with it. The new procedure is described here. I did it for my own tool without any problem. --NicoV 11:21, 10 April 2010 (UTC)
 * Ok! Thanks. I applied this method and my login now works. Regards, Hexasoft 11:49, 10 April 2010 (UTC)

I experienced the same problem with my bot on Wikia after they updated the software. Unfortunately, when I try to get the token in the first request I only receive the token itself but not the cookieprefix or sessionid for the second request (which also returns a NeedToken error). I checked the HTTP headers and they don't send a cookie, either. It would be great if someone who fixed the problem for his bot could tell me how he got the sessionid from the response. Have a nice weekend, 24.182.167.38 20:43, 17 April 2010 (UTC)
 * Send a first login request (with lgpassword and lgname) to receive the token, then send a second login request (with lgpassword, lgname and lgtoken).
 * http://fr.wikipedia.org/w/api.php?lgpassword=XXXXX&action=login&lgname=ZZZZ&format=xml
 * http://fr.wikipedia.org/w/api.php?lgtoken=YYYYY&lgpassword=XXXXX&action=login&lgname=ZZZZ&format=xml
 * --NicoV 15:49, 18 April 2010 (UTC)
 * Thank you for your fast response; I fixed my mistake. In case anyone else has the same problem, my script is written in JavaScript and AJAX and I was using a PHP proxy to relay the request to the wiki server. The wiki server returned the correct response including the HTTP cookies back to the proxy but my proxy only returned the XML part of the response, not the session cookies. Therefore, on my computer I did not see any cookies when I was looking at the HTTP headers. I had to change the proxy script so that the cookie would be returned as well. Thank you again for your quick answer. --24.182.167.38 19:17, 18 April 2010 (UTC)

I am doing the same thing. I make a second call with the lgtoken value set. How do you pass the cookie in PHP? What I did was have the CURLOPT_HEADER be TRUE, so that I would get the header back. Then I parsed the header for the session id, then did this in the second API call:

curl_setopt ($curl_obj2, CURLOPT_COOKIE, 'wiki_session='.$sessionId);

But it's very unpredictable. It works sometimes, doesn't at others. Is there some way to do this without using Snoopy. I'm working in a corporate environment and use of open source isn't encouraged, unless it's really well established. It's a big thing that I'm using MediaWiki at all. --Jogjayr 23:13, 8 June 2010 (UTC)

Throttling setting
How does one change the throttling setting to something other than 5 logins per 300 seconds? Thanks, Tisane 13:20, 6 May 2010 (UTC)

Take a look here: Manual:$wgPasswordAttemptThrottle JRWR / wiki@jrwr.co.cc

is there a possibility to...
...check if someone is online (login) or not? And is it possible to add this in a wiki with mediawiki 1.15.1? --80.144.42.121 12:18, 11 August 2010 (UTC)
 * Extension:WhosOnline. Max Semenik 12:51, 11 August 2010 (UTC)
 * Yeah... I know this function, but WhosOnline works with edits. I think of something that works with the button Log in/out... --80.144.42.121 13:13, 11 August 2010 (UTC)

Automate Browser Login
Is it possible to use this API to login on behalf of the browser?

I have successfully performed a login and login confirmation, but that just allows my server to communicate with the Wiki via the API calls.

What I really wanted to do was to log in on behalf of the user (my web site was going to store their mediawiki username and password, with their permission), then allow him or her to continue browsing. However, as my script can't set the username, userid, session and token cookies for a different domain, I'm beginning to think this can't be done.

Any suggestions?

Thanks — Preceding unsigned comment added by 86.179.250.84 (talk • contribs) 08:02, 15 October 2010‎
 * I don't think you can do that very easily. (You could probably do something with forcing your users at site A to load an image from your mediawiki site that sets the cookie based on information received from the server of site A, like how central auth does multi-wiki logins, but that'd probably require you to write an auth extension). Bawolff 22:12, 19 October 2010 (UTC)

logging in with FauxRequest
Hello, here is a newbie question: I'm trying to upload an image to my own Mediawiki installation from an extension, and I need to log in to do that via the API. However: $request = new FauxRequest( array( 'action' => 'login', 'lgname=' => 'mylogin', 'lgpassword' => 'mypassword', ));	$api = new ApiMain( $request); $api->execute; ...returns as result only 'NoName', supposedly to mean that lgname is not defined. What am I missing?

rotsee 13:11, 17 April 2011 (UTC)

'lgname=' => 'mylogin', is misspelled.

try: 'lgname' => 'mylogin', — Preceding unsigned comment added by 2.163.153.6 (talk • contribs) 22:38, 12 November 2014

How to Login from desktop window application?
There is a website built with MW 1.18.2, which requires users to log in - without this you cannot access any page in it. I have valid credentials to log in manually from browser, but I need to be able to do the same from my windows forms application (C#): when user clicks on a button I have to show (or navigate to) certain page from the website, and for that I have to login programmatically first. I see the examples in PHP and JScript but being newbie in that web staff I have no idea how to use them.

Any help would be greatly appreciated.

Thanks. — Preceding unsigned comment added by 2013‎ 206.172.0.204 (talk • contribs) 12:40, 18 October

Problem using login API on Waze wiki
Hi,

My application, WPCleaner works fine on Wikimedia wikis (Wikipedia, Wiktionary, ...), but my attempts to make it work on Waze wiki have failed for now. I don't understand why login doesn't work on Waze wiki. Would someone have an idea about this problem ?

The first call to the login method for waze wiki returns a "NeedToken" answer as usual, with a session id in the answer and a wikidb_session cookie. When I call the login method a second time, with wikidb_session cookie set and the token, the answer from waze wiki is again a "NeedToken" with a different session id and wiki_session cookie.

Apart from this, the only difference that I noticed is the cookie name: enwikiSession for enwiki, wikidb_session for waze (no uppercase letter and an underscore).

Here's what my logs are saying when calling enwiki login:

And the logs when calling waze wiki login: Token and session id returned in the second call are different than the one returned in the first call.

Any idea on what's going on? --NicoV (talk) 22:14, 11 July 2014 (UTC)
 * Problem found: apparently Waze server has a problem with multiple Cookie headers... I forced the use of a single Cookie header and it seems to work now. --NicoV (talk) 15:44, 14 July 2014 (UTC)

OAuth
My limited understanding of Extension:OAuth is that using action=login is not required after oauth. Are their other ways to login without action=login? The first sentence and others could be slightly improved to indicate that there are other ways to login to the API without this action. John Vandenberg (talk) 10:15, 5 June 2015 (UTC)
 * Using centralauthtoken (from Extension:CentralAuth) also avoids needing to use action=login. There might be other extensions that do the same sort of thing.
 * In all these cases it's more or less the same as when you have the cookies set after logging in normally: you have an authenticated session already so you don't need to use action=login to get one. Anomie (talk) 13:44, 5 June 2015 (UTC)
 * Thanks for a bit of background. I've taken a crack at rewriting the intro.  Would appreciate timely copyedits before it is sent off to translators, or a revert if necessary.
 * I see JavaScript clients are mentioned in the section below the intro, so that might be a good spot to mention OAuth, temporarily at least. John Vandenberg (talk) 01:07, 6 June 2015 (UTC)
 * Looks good to me. Anomie (talk) 13:22, 8 June 2015 (UTC)

action=login
Is "action=login" deprecated or getting deprecated? API in en-wiki says that we should use "action=query&meta=tokens&type=login" now. --Infovarius (talk) 21:04, 18 March 2016 (UTC)
 * action=login is not deprecated, but getting the login token via action=login is. You should get the login token via action=query&meta=tokens and then use that to login via action=login. --Cgt (talk) 21:07, 18 March 2016 (UTC)
 * Thanks for the answer. Now I am trying to do so. I'm getting "success" when logining through API sandbox, but I'm getting "WrongToken" constantly when doing the same requests in my program (URLFetch in Wolfram Mathematica). Also when I feed logintoken from sandbox. Before the change to "meta=tokens" it was possible to login. What can be the reason? Infovarius (talk) 21:43, 18 March 2016 (UTC)
 * Be sure you're saving the cookies returned from your request to action=query&meta=tokens, and then send them on your request of action=login --Ciencia Al Poder (talk) 11:50, 20 March 2016 (UTC)
 * Thanks, but not working. I am saving the cookies and send them on request of action=login. Something strange that first request doesn't require user login... Why after API changes developers don't update documentation here? --Infovarius (talk) 21:49, 20 March 2016 (UTC)

Localized error messages
Hello! I tried to tack on a  parameter to the clientlogin sample[0] but the error messages are still in English:

"error": { "code": "loginmustpostparams", "info": "The following parameters were found in the query string, but must be in the POST body: logintoken", "*": "See https://www.mediawiki.org/w/api.php for API usage" }

I know this particular error is due to developer misuse but generally speaking, is there a means to localize these responses so clients can present a human readable message to their users? Thanks!

[0] https://www.mediawiki.org/w/api.php?action=clientlogin&uselang=es&username=Example&password=ExamplePassword&loginreturnurl=http://example.org/&logintoken=123ABC


 * Sadly, it seems like it's a hardcoded message: . There has been an effort to localize the help system of the api and some error messages. You can request messages like this to be localizable.
 * Also note that errors from api contains a code (loginmustpostparams in this case) that you can use to replace the error message with a custom one when presenting the error to the user. That, of course, requires you to know beforehand all possible error codes that particular api module can throw... --Ciencia Al Poder (talk) 09:49, 5 October 2016 (UTC)
 * FYI, the relevant task is T47843. And it's on my short list of things to do next time I have time for major API work. Anomie (talk) 13:42, 5 October 2016 (UTC)
 * Thank you both! Niedzielski (talk) 20:22, 5 October 2016 (UTC)

Support of both kinds of credentials?
Obviously, API:Login supports two kinds of credentials (beside OAuth): Up to now, I'm not able to detect a way, how both kinds of credentials could be used by a client. It looks like usage of one kind of credential excludes the usage of the other one. Did I miss something?
 * 1) main-accounts → action=clientlogin is required
 * 2) bot-accounts → action=login is required

To illustrate my concerns:  I'm working at development of LrMediaWiki, a plug-in for Adobe Photoshop Lightroom which enables Lightroom users to upload images to a MediaWiki instance. Users need to login to upload images. Due to usability reasons, user's credentials are stored by the plug-in and the latest stored credentials are used by following logins/uploads – this means: users shouldn't be annoyed by typing credentials at every usage of the plug-in. I mention this, because I don't know, if this plug-in should be considered to be an "interactive" client or not.

Recently I detected deprecated API calls related to the login at the plug-in's log file: According to these messages and the methods recommended at API:Login, I consider to use action=clientlogin for future versions of LrMediaWiki to resolve the deprecated issues. I'm not sure, if this decision was right. Maybe, action=login might fit better to LrMediaWiki, but it seems this would support only bot-accounts, not main-accounts.
 * Fetching a token via action=login is deprecated. Use action=query&meta=tokens&type=login instead.
 * action=tokens has been deprecated. Please use action=query&meta=tokens instead.
 * Main-account login via action=login is deprecated and may stop working without warning. To continue login with action=login, see Special:BotPasswords. To safely continue using main-account login, see action=clientlogin.

LrMediaWiki needs to support both kinds of credentials, main-accounts and bot-accounts. Up to now, LrMediaWiki works in a "traditional" way of login and supports both kinds of credentials, but yields to the mentioned deprecated messages. My tries to resolve the deprecated issues (first determine a login token, then using action=clientlogin) works successful with main-accounts, but bot-accounts don't work. Therefore I assume, action=clientlogin doesn't support bot-accounts.
 * Testing bot-accounts with a non-WMF MediaWiki 1.28.0 instance yields an error message "The supplied credentials could not be authenticated." (If $wgLanguageCode is set to "de": "Die angegebenen Anmeldeinformationen konnten nicht überprüft werden.")
 * Testing bot-accounts with commons.wikimedia.beta.wmflabs.org running MediaWiki 1.29.0-alpha results to an error message "Incorrect password entered. Please try again."

Any idea, how the LrMediaWiki client could/should support both kinds of credentials? --Hasenläufer (talk) 05:11, 3 January 2017 (UTC)
 * action=clientlogin was written because there's no way to make action=login reliably work with AuthManager. Main account login must use AuthManager. Note that main account login need not depend on a username and password, it could as easily be a redirect to Google's authentication service if appropriate extensions are installed. It might also require a captcha, or require input of a second-factor TOTP token, or require some other user interaction.
 * Bot passwords were created specifically to bypass AuthManager so existing bots could continue working using action=login instead of being forced to be rewritten to use OAuth. There's no sane way to make them work inside AuthManager, so action=clientlogin isn't going to accept them.
 * If you want to support both types in your framework, the application will need to decide which it's going to use and choose the appropriate methods. It's unlikely to be useful to present the end user with the choice: either you're interactive so you should use action=clientlogin, or you're noninteractive and should use OAuth or action=login with credentials saved in your configuration. Anomie (talk) 15:37, 3 January 2017 (UTC)