-
Notifications
You must be signed in to change notification settings - Fork 257
Mobileclient login stopped working with app passwords #620
Comments
I'm still able to log in using an app-specific password with 2FA-enabled accounts. |
Same issue. Getting "NotLoggedIn" exception |
CI started being failing to log in. I forget if it's using an app password or not. |
Interestingly, "allow less secure apps" was turned off for that account. I'm pretty sure it was on in the past, so maybe Google accidentally toggled it. I'll find out shortly whether it makes a difference. |
On my 2FA account, Google would not let me enable less secure apps. |
That solution worked for me. Enabled it at https://myaccount.google.com/lesssecureapps and login worked again. |
It's definitely intermittent. I have a batch job that runs several different gmusicapi calls, instantiating a mobileclient each run, and some of them work and some don't. I can re-run the failures and eventually get them all to run. I'm using 2FA, and also not able to change the less secure app setting. |
I had the same issue. Using one of the Android Id from |
I cannot login using a new device. I must use an older Android ID, but cannot remember how to get to the |
For now, I'm just doing this. It's working for me as a workaround. logged_in = False; |
thats so brute forcey |
@tchrischan it might be a good idea to look into something like https://pypi.org/project/retrying/ or the newer https://pypi.org/project/tenacity/ , and consider adding some delays and a maximum number of tries. |
|
@fergyfresh yes, yes it is. But it's just a workaround. @dsears's code is an improvement (thanks), but I also did not want to spend too many cycles fixing behavior we don't even know will be permanent (especially with the announcement of Youtube Music) to have a more elegant solution. It only fails for me once or twice before it works, so brute force retying is fine for me. YMMV. |
@tchrischan i used this to generate a fake id https://www.myfakeinfo.com/mobile/get-android-device-information.php and then that only failed once and exceptioned out with the exact android id set that are verified on my account. I manually grabbed one of those and now i'm in every time using |
Brute forcing doesn't work for me I'm using an App Password, and it's definitely working because the "last used" field in my App Passwords page on my Google Account updates when I attempt a login. Not sure where to really go from here |
Never mind, I managed to solve my own problem using https://accounts.google.com/b/0/DisplayUnlockCaptcha |
Using that DisplayUnlockCaptcha link worked for me, but trying to play any mp3 results in 403 to from gmusicapi to Google API |
@BigMunch. Try using the app password on another mac address. It wont work ;) |
Not sure what this attitude is about. There was no talk about it being an issue with different machines when I first responded. And I haven't been part of the discussion since. Also, I tried it on 3 different machines when I first responded. All worked first try for me then. I just retried them now, and they all worked first try for me. TL/DR Welcome to my ban list. |
I meant to say NEW mac address. It seems to be an issue with using the same app password with a new machine. At least, thats what most of this thread is about. Also there was definitely no attitude implied there (and don't see how tagging a maintainer that said there's no issue when there is clearly an issue is somehow attitude), I was just trying to poke at the fact that there is seemingly a bigger issue somewhere here that we haven't been able to figure out. It's probably only for 2FA users too, which you might not be using. Sorry you thought I had attitude. I apologize if you're having a bad day. I'm just trying to get this issue a higher priority because it's flowing downstream pretty hard to my app. |
I looked into this for a bit in the context of CI. I set up a proxy on a server of mine, went through the displayUnlockCaptcha flow, and was surprised to see I still couldn't log in when proxying Travis through it afterwards. I noticed two things when investigating more. First, only the Second, when the master login fails Google provides a link for the client to go through the browser-based flow. For example, my response looks like
Opening the link in a browser works, but only sets the resulting tokens as cookies for the browser. I don't see a straightforward way to get Google to present them so users can easily copy them out. Given that (as far as I can remember) the master_login flow was just a workaround for converting sso credentials to oauth, I'm thinking it's time to just deprecate the sso interface and move to normal oauth instead. In other words, the mobileclient would get an interface to mirror the musicmanager's, and we'd eventually remove the old email+password one. Thoughts? It'd be a big breaking change, but I figure it's for the best in the long run. |
I've got this working on the develop branch. If you want to try it out:
Then do something like:
python -c 'from gmusicapi import Mobileclient as MC; m = MC(); print m.oauth_login("<device_id>"); print m.get_all_songs()[0]' |
@simon-weber I tried the code to use the oauth in the mobileclient and it works very well (tried with python3) |
Alright, OAuth support is out in 11.1.0. I'm going to close this since it should address the original problem from this issue; feel free to open a new one if you run into issues. |
As of October 4, I'm no longer able to authenticate the Mobileclient interface using an app password on my 2FA-enabled account. It was working on October 3.
I've tried:
Is it just me, or is Mobileclient broken for other 2FA users as well?
The text was updated successfully, but these errors were encountered: