Last modified: 2011-01-25 00:16:55 UTC
The API occasionally returns 'WrongPass' for a login attempt despite the password sent being correct. Based on what I am doing at the time I think this is due to the login throttle being activated somehow. Desired behavior: * The login throttle should never be tripped as long as no incorrect password is ever sent. * When the login throttle is tripped, the error should not be WrongPass. Query sent: action => 'login' format => 'xml' lgname => '******' lgpassword => '******' XML received: { 'login' => { 'result' => 'WrongPass' } };
I should be more clear that I don't know for sure that this is the login throttle. It happens intermittently, and I cannot seem to make it happen by just logging in very fast. But since the bot is reading the same file for the password each time, and based on the debugging output, the password being sent is correct. The same code, reading the same password, will start working again after some delay.
the older throttle code would have returned a 'NeedToWait' result. the new throttle code returns a 'Throttled' result.
Yes. I just ran into the bug again a moment ago. First I got a 'WrongPass' response a few times. Then I hit the throttle and got 'Throttled' for 300 seconds. Then I was able to log in successfully. All of this was with the exact same code. Is three anything I can do to help debug this?
(In reply to comment #3) > Yes. I just ran into the bug again a moment ago. First I got a 'WrongPass' > response a few times. Then I hit the throttle and got 'Throttled' for 300 > seconds. Then I was able to log in successfully. All of this was with the exact > same code. Is three anything I can do to help debug this? > The only cause I can think of is that one server is broken and rejects your login while the others don't (that'd explain the intermittent part). It'd be nice if you could aggressively try to reproduce the bug, logging in and out over and over again, and log the server name and success/failure for each attempt. If my theory is correct, all failures will come from the same server (or a few servers in the worst case), while the successes will be pretty much evenly distributed over the rest. For the login request, use format=xmlfm (or another pretty-printed format), which will get you pretty-printed XML (or JSON or ...) in HTML with a comment after the closing </html> saying something like <!-- Served by srv103 in 0.047 secs. --> where srv103 is the server name. Distinguishing between success and failure is a little harder when working with HTML gibberish your client doesn't understand, but I guess searching for the word "Success" (or "WrongPass" or "Throttled" or ...) should do the trick.
I am also having this problem. I use Hughesnet and cannot stay logged in to my install of the newest version of mediawiki. I can stay logged in to older versions of mediawiki with no problem, but cannot administrate my own wiki because of this.
(In reply to comment #5) > I am also having this problem. I use Hughesnet and cannot stay logged in to my > install of the newest version of mediawiki. I can stay logged in to older > versions of mediawiki with no problem, but cannot administrate my own wiki > because of this. > Ignore last comment, clicked on the wrong bug when submitting my comment.
Setting to WORKSFORME, since nobody has reported this in a while, and I don't notice it anymore.
