EionRobb
[Bug]: purple-googlechat is unable to login
Side note, it would be super cool if you could use the Gnome Online Accounts to pull in any Google account credentials automatically!
Yeah unfortunately google disabled the authentication mechanism that this plugin was using. Also this plugin can't use a normal google login method because then it wouldn't have access to the google chat api as google doesn't export it to third party oauth applications.
There's been a considerable amount of work put in in the background, but there's no solution yet. However it looks like there may be a solution but this plugin is going to need to need a significant amount work to get to that point.
TL;DR stuff is broke, it's going to take some time to get it all sorted.
Is there anything end users can do to help facilitate sorting out potential solutions? :)
Not really it's a mess. But if you can think of any other google chat clients that aren't the ios version, android version, or the web version that might be useful.
I was getting all keyed up to mention mautrix/googlechat, a GChat puppeting bridge for Matrix, but glanced at auth.py and saw:
Logging into Hangouts using OAuth2 requires a private scope only whitelisted for certain clients. This module uses the client ID and secret from iOS, so it will appear to Google to be an iOS device
and
https://github.com/mautrix/googlechat/issues/85
Alas.
It seems that tulir is looking at it too, at least, so hopefully once a solution is found it can be implemented by all bridges. If it becomes possible and helpful for end-users to assist with traffic sniffing, testing, etc I'm sure you'll have some volunteers!
I was getting all keyed up to mention mautrix/googlechat, a GChat puppeting bridge for Matrix, but glanced at auth.py and saw:
If you look closely at that repository you'll see my name too :) Actually I forgot he threw away the history when he pulled hangups in maugclib, so you won't see my name ;)
I really hope there is some kinda work around. I wanted to get my son setup on pidgin without having to deal with the browser all the time
So I know the plugin is looking for the oauth, is there a way to connect with the app password setup that google still has?
Any update on a fix to get Google Chat to work? I too hate the browser window. I miss my Pidgin and now have to keep Pidgin and Chat open at the same time. Please, please, please :)
Looks like they resolved it by using the web app API? https://github.com/mautrix/googlechat/pull/89
Looks like they resolved it by using the web app API? mautrix/googlechat#89
Kind of. If you look closely you'll see I'm the one that did the work. The TL;DR is that the web login is used instead of the oauth out of band auth that was previously used. That requires an embedded browser, something we don't have and can't easily make work with pidgin right now. That said, I suppose we could hack together a patch that would allow you to enter the 6 cookies that are necessary and with a few other changes it could work, but that's less than ideal.
Do the cookies have a reasonable expiry time?
Cookies are at least plain text, so it's still kind of just a string like an oauth token if you squint your eyes closed hard enough. Still a pain to grab/paste nicely compared to oauth, but beggars can't be choosers.
Sure would be nice if Google hadn't killed XMPP! (and, you know, everything else they've killed)
Yeah they're pretty clear but you need 6 of them and they'll get refreshed automatically from what I've seen since I started working on this back in April.
The real question here is if @EionRobb would want a patch to do this. But the cookie capture procedure differs a bit between firefox and chrome and I haven't tested other browsers. See https://github.com/mautrix/googlechat/blob/master/maugclib/README.md
Thanks for the info! There's presumably an automated way to get the cookie info out of Firefox / Chrome like an addon/extension†? But that's getting into the realm of hacks supporting hacks...
† Though maybe not since auth info lives there and browsers care about security? I last properly looked at getting cookies out of the browser around the IE6 days it feels like, so maybe I should stop guessing
Thanks for the info! There's presumably an automated way to get the cookie info out of Firefox / Chrome like an addon/extension†? But that's getting into the realm of hacks supporting hacks...
Nope, all of the cookies are HttpOnly which means they can't be read from JavaScript. This is why an embedded browser is necessary.
I mean from a user perspective to get them in to mau/purple in a slightly easier way than devtools- I seem to be able to export them using cookies.txt. A few minutes of scripting would have the python dict from that!
Edit: I don't want to clutter the issue here too much, just thinking of ways to streamline the process for end users to 'do the needful' if hacks are all that are likely to work
I just opened a private window, logged in, and checked the cookies on "chat.google.com"
The only ones I see are: /OSID, /__Secure-OSID, /OTZ, /COMPASS, and /u/0/webchannel/COMPASS.
SSID, SID, and HSID reside in ".google.com"
I've been authenticated to google chat in Pidgin for months, without it kicking me out.
There are several add-ons for both FF and Chrome that support exporting cookies to a text file. I think that adding an "import cookies from file" option to the plug-in should be doable. The more technical users can edit blist.xml directly.
Ugh, just realized why I haven't heard from any of my friends on pidgin... looks like was stuck waiting for auth. I guess my oath key was no longer valid (set it up a year ago). So there is still no way to purple-googlechat to work now?
Until this is resolved it might be a good idea to mention something at the top of the readme? Or at the very least pin this issue, so people (like me) don't spend all sorts of effort and time before finding out all of the other information on the interwebz is outdated and things currently don't work :disappointed:
While my home computer lost its connection a couple months ago, I still have access to both a Windows and Linux computer which are still able to connect to google chat. Is there any information I could gather from either of these machines which might help in solving this problem, or is it simply a matter of time before those machines also expire?
In the meantime, I finally gave up and just set up my own XMPP server. Obviously can't trust Google or any of the other sites to play nicely.
Is it possible to do the authentication process in a browser and copy the cookies over using the plugin as it exists today? Or does that workaround also require a patch to the plugin to make it use those cookies?
Understood that this is still an ongoing issue, just putting my hand up and saying that i attempted this today and google is still being annoying.
I have same problem. Embedded browser surely can't be an option because purple-googlechat also was for BitlBee, which is text-only (unless you have some text-only web browser you can embed that's going to get the information).
I have a maybe solution - but it's a maybe and needs a bit of verification from someone else to see if it's viable.
- Open this link in an incognito browser window (edit: it might only work in non-incognito?)
- Open dev tools, switch to Network tab and enable 'Preserve log'
- Login until you get the "401 error" page
- Look for the last "batchexecute" in the network list
- Look for an X-Chrome-Id-Consistency-Response header which should have "authorization_code=4/...."
- Copy the code, starting with and including the 4/
- Cross fingers
- Paste the 4/... code into Pidgin in the popup
I tried this method, and was able to copy the 4/ auth code, but login fails with "Bad Request".
At first, 'Preserve log' should be enabled in dev tools - otherwise, it'll be cleaned after the page reload. And it works also in non-incognito. But, I got "Bad Request" when I wanted to log in to Pidgin as @bssb already mentioned.
I tried this, in both Firefox and Chrome, in both incognito/private and not, and for me it failed in a different way: the login flow ended with a 400 not a 401, and there were no X-Chrome-Id-Consistency-Response headers in any of the transactions.