"Invalid password" when calling login method over XML-RPC

Apr 13, 2017 21:03

A week or two ago my LJBackup client started being unable to login - I didn't change anything (I think!), but now I always get an "Invalid password" response.

I'm using the XMLRPC method with the challenge-response scheme.

Anyone else seeing something similar?

Thanks!

client: authentication, client: xmlrpc

Leave a comment

pauamma April 14 2017, 05:18:24 UTC
Have you (and or your users) accepted the new LJ ToS (using the web interface) for the user account(s) you're trying to back up? This seems to be a common failure cause, if it started failing in the timeframe you describe.

Reply

gregstoll April 14 2017, 12:39:33 UTC
Sorry, I forgot to mention that I did accept accept the ToS by logging in to the website.

Reply

pauamma April 14 2017, 13:15:09 UTC
OK, this sounds like you're reporting about your own use of your client as gregstoll, and that you were able to log in using the web interface to do stuff like post this entry. So you probably got the Javascript "please accept our new ToS" popup at some point, checked the "I accept" box (or whatever it's called - I forgot) and clicked Continue. Before I proceed under wrong assumptions, is the above correct?

Reply

gregstoll April 14 2017, 13:52:57 UTC
Yes, that is correct. (Before I did that, when I ran the script I got a pretty helpful error message saying I need to accept the ToS; now I just get "Invalid password")

Other people have reported running into the problem with their login info using my client, but I've just been testing with logging in as myself because I can be triply-sure about my password :-)

Reply

pauamma April 14 2017, 16:35:09 UTC
OK, I asked Dreamwidth support people and checked the past week's import-related support requests, and there seems to be none about failing passwords. I would expect there to be some, what with imports to DW currently happening by the thousands, if there was any recent LJ-induced glitch along those lines. So I suspect the problem is on your end. Are you 100% positive that there was no change on your side, in either your own code or the Ruby framework/libraries/whatever it uses, before the problem reports started coming in?

Reply

gregstoll April 14 2017, 20:19:14 UTC
OK, that does seem like it's very likely to be my fault. I'll go back and look at the history and try a few things.

Thanks a bunch! This is very helpful.

Reply

pauamma April 14 2017, 20:45:24 UTC
You're welcome!

Reply

gregstoll April 15 2017, 00:36:27 UTC
...and indeed it was my own fault. Thanks for giving me the impetus to look again, and sorry for wasting everyone's time!

Reply

pauamma April 15 2017, 03:16:09 UTC
Glad I could help!

Reply


Leave a comment

Up