Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client not secure for android messages login #441

Closed
ThePianoMan2255 opened this issue Jan 17, 2024 · 21 comments
Closed

Client not secure for android messages login #441

ThePianoMan2255 opened this issue Jan 17, 2024 · 21 comments
Labels
bug Something isn't working

Comments

@ThePianoMan2255
Copy link

Describe the bug
When attempting to sign in (not with a QR Code) it says it is not a supported browser / secure. See attached image.

To Reproduce
Steps to reproduce the behavior:

  1. Open the app
  2. Click on sign in
  3. Attempt to sign in
  4. See error

Expected behavior
Should allow you to login in a supported secure setting.

Screenshots
image

Desktop (please complete the following information):

  • OS: PopOS 22.04 LTS
  • Version: Latest Deb Package: 5.4.2
@ThePianoMan2255 ThePianoMan2255 added the bug Something isn't working label Jan 17, 2024
@mtballday
Copy link

It seems like the latest version of the phone app no longer supports pairing with the QR code (at least, I can't find it now), so this problem makes it impossible to pair.

@adelphi23
Copy link

I got stuck on this too, but have a complicating factor.
In my Macbook Pro M1 Ultra (2021) it worked. That is, I did not the the error message shown above by OP.
In my Macbook Air M2 (2022) it did not. That is, I did get the error message and cannot pair my computer.
It might be that between the two installations the phone app was updated, losing its support for QR-based pairing. I cannot recall doing QR pairing, though.

@sansbyte
Copy link

sansbyte commented Feb 18, 2024

I get the same message as the original post - the "This browser or app may not be secure".

However, while troubleshooting, I stumbled across a workaround that lets me login. I tried starting the program with the --debug switch to try getting more troubleshooting information to share here.

$ ./AndroidMessages --debug
[61919:0217/185412.944387:ERROR:node_bindings.cc(244)] Error parsing Node.js cli flags 
electron: [DEP0062]: `node --debug` and `node --debug-brk` are invalid. Please use `node --inspect` and `node --inspect-brk` instead.

So I then tried using the --inspect switch, because why not. The program started and let me login. This is the command output, for what it's worth.

$ ./AndroidMessages --inspect
Debugger listening on ws://127.0.0.1:9229/961741b9-d61c-405d-8c49-44300d11d83a
For help, see: https://nodejs.org/en/docs/inspector
APPIMAGE env is not defined, current application is not an AppImage
[74550:0217/191924.083478:ERROR:nss_util.cc(349)] After loading Root Certs, loaded==false: NSS error code: -8018

After logging in and closing the program, I can open it again without the --inspect switch and I'm still logged in.

@adelphi23
Copy link

@sansbyte:
Thanks a lot. It worked for me!

@maelchiotti
Copy link

Same error on windows 11.

@innesst
Copy link

innesst commented Mar 5, 2024

I also got the message when trying to login, but then I added the @gmail.com to my username and it worked.

@maelchiotti
Copy link

I also got the message when trying to login, but then I added the @gmail.com to my username and it worked.

Doesn't work for me.

@mcortt
Copy link

mcortt commented Mar 16, 2024

Login via the top sign in option and NOT the one in the page. Also, use your full email address.
image

@maelchiotti
Copy link

Login via the top sign in option and NOT the one in the page. Also, use your full email address. image

Still does not work for me

@adelphi23
Copy link

Does not work on Fedora 40. Tried with the --inspect toggle using the CLI and also clicked on the top sign. All to no avail. It is the app since the web version works.

@adelphi23
Copy link

After trying a few times, the sequence:
./AndroidMessages --inspect (click on the top button, use full gmail)
close
./AndroidMessages
worked. No changes in any other parameter. It is somewhat random.

@caseyredisatwork
Copy link

For me (running an Arch-based Linux distro), --inspect by itself did not work. I needed to use --inspect, then I had to select "Remove Account", click the red (-) icon next to my account, say "Yes, remove" and then re-enter my credentials. After that, I closed the app and re-ran without --inspect and it still worked.

I thought maybe removing the account itself was what worked so I tried that after things were working from the above but removing didn't resolve the issue without first running --inspect. YMMV, I didn't want to mess around with it much more after getting it to work twice the original --inspect way

@drislands
Copy link

I experienced this issue as well, on Linux Mint 21.3. The --inspect trick did work for me. I'd like to try to investigate why this is failing and see if there's a permanent fix that can be put in place, so I've forked the project. Fingers crossed I maintain focus long enough to find a solution.

drislands pushed a commit to drislands/android-messages-desktop that referenced this issue Jun 4, 2024
Modified how the user agent is set when sending headers. There were two issues that I was able to identify.

First, the Google sign-in page sends requests to the youtube.com domain sometimes, so the existing replacement effect was not always firing. Adding a url entry for this domain fixes this problem.

Second, Google sometimes doesn't like the hard-coded user agent this project was previously providing. I have no idea why -- this Electron/user agent/Google problem has been ongoing for years. I've solved this problem this time by instead taking the user agent Electron would have passed by itself and stripping out only the Electron-specific component.

I don't know how long this fix will last, since Google seems intent on being opaque about how they determine if a browser is secure or not. Fingers crossed.
@drislands
Copy link

https://github.com/drislands/android-messages-desktop/tree/bugfix/441

I've attempted a fix. It's working consistently for me now, but I'd like to see if it works for other people before I open a PR.

If there's anyone experiencing this issue, can you clone my project from the link above and see if it works for you?

@Vilacard
Copy link

Vilacard commented Jun 6, 2024

I haven't used github much so I'm not really sure what you mean by cloning your project. I thought I could maybe just download your code as a .zip then replace something in my Android Messages install folder with the most recently changed files you did, but there doesn't seem to be a background.ts in my install folder.

@maelchiotti
Copy link

@Vilacard you cannot juste replace the files, they need to be compiled first. I do know how to use GitHub but I don't have the time right now to setup the environment, would it be easy for you @drislands to build a Windows executable?

@drislands
Copy link

@maelchiotti I'll see if I can package this up. I haven't done this for a JS project before so it may take some doing.

@drislands
Copy link

Turns out that's not hard to do.

@maelchiotti @Vilacard try the EXE attached to this release. I don't have a Windows machine I can test this on, let me know if there's any issues with getting this working and I'll try to sort it out.

https://github.com/drislands/android-messages-desktop/releases/tag/411-fix.1

@Vilacard
Copy link

Vilacard commented Jun 6, 2024

Thanks! I installed it and I am able to successfully login.

@maelchiotti
Copy link

Thank you! I will try it tomorrow to confirm if it's working.

@maelchiotti
Copy link

@drislands Worked perfectly, thank you so much

OrangeDrangon pushed a commit that referenced this issue Jun 8, 2024
Modified how the user agent is set when sending headers. There were two issues that I was able to identify.

First, the Google sign-in page sends requests to the youtube.com domain sometimes, so the existing replacement effect was not always firing. Adding a url entry for this domain fixes this problem.

Second, Google sometimes doesn't like the hard-coded user agent this project was previously providing. I have no idea why -- this Electron/user agent/Google problem has been ongoing for years. I've solved this problem this time by instead taking the user agent Electron would have passed by itself and stripping out only the Electron-specific component.

I don't know how long this fix will last, since Google seems intent on being opaque about how they determine if a browser is secure or not. Fingers crossed.

Co-authored-by: Doc Islands <dont@email.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests