Closed ozkcs closed 4 years ago
I can confirm this occurs after 9 September. Maybe WhatsApp has just got a new update.
@cerolcs You can get it to work again by removing the folder session
created by sulla.
It seems the issue is similar to #40.
Try changing the useragent string at line 9 of controllers/browser.ts
at src
and then rebuild or at line 55 of controllers/browser.js
at dist
to something else. The hard-coded one may have been flagged.
delete session folder, instal puppeteer:
npm install puppeteer --unsafe-perm=true --allow-root
delete session folder, instal puppeteer:
npm install puppeteer --unsafe-perm=true --allow-root
just don`t work(
@uargb @NewZeek @UnKnoWn-Consortium @cerolcs
I have implemented a fix (puppeteer-extra-stealth) to stop whatsApp identifying puppeteer (https://github.com/berstend/puppeteer-extra/tree/master/packages/puppeteer-extra-plugin-stealth)
Please try it out in sulla-hotfix (v.1.2.2) and let me know if it works for you.
https://github.com/smashah/sulla https://www.npmjs.com/package/sulla-hotfix
on it
@smashah no, it doesn`t
still "loading qr" but with sulla-hotfix added some non-unicode symbols when "ctrl-c" √ Initializing whatsapp i Authenticate to continue \ Loading QR�訡��: �� 㤠���� �������� ����� � �����䨪�� 2408, ���୨� ����� 6812. ��稭�: �� ���� �� ������� �⮣� ������� �� ����饭. �訡��: �� 㤠���� �������� ����� � �����䨪�� 5336, ���୨� ����� 6812. ��稭�: �� ���� �� ������� �⮣� ������� �� ����饭.
No idea what those chars are. I think there's some sort of mouse movement detector on this because when I run it with headless=false with a chrome isntance it works fine. At this point, we're just playing whack a mole with WhatsApp.
I tried some mouse movements, no luck. I'm happy to try any other ideas if there are any.
In my case it started working when i leaved only the first 7 arguments in the puppeteerConfig.chroniumArgs
On windows occasionally it hangs at loading QR. If I change browser.js to headless: false, then I can see that Whatsapp detected something and therefore it showed a message: "WhatsApp requires Chrome 49+" instead of showing the QR code. But after that somehow it works on Windows (not sure how it started to work), and it remembers the session on the next load.
On Linux it's a different story: QR loads fine the first time, but once a session is established, a reload will prompt Loading QR forever, unless I delete session folder and start again. I guess it detects something after reload with session folder exists, but I cannot have headless:false to check because it runs on remote server without a desktop. No difference with sulla-hotfix.
@hongnk one option (I tried and it works for me) is to have a virtual display in the server using xvfb
and changing browser to headless: false
.
@danielcardeenas It seems for now that the only way to avoid the dreaded "Upload Google Chrome" message is either killing the session (but then the QR code has to be scanned every time some other WhatsApp Web window is open) or to run chromium with headless: false
.
The latter option seems more suitable for automation but requires manually changing the code after npm install
which is not ideal if you have some continuous deployment system. Would it be possible to change the code to make the headless
parameter configurable? Maybe via an environment variable?
@OskJonsdottir https://github.com/smashah/sulla#custom-set-up
Also, I've not found that setting headless:false makes it any more reliable over many restarts.
Just FYI, it may be beneficial to use Whatsapp Web's own desktop client's user-agent. You can see some examples here:
Removing session folder will resolve this issue. Step 1. const fse = require('fs-extra') Step 2. fse.remove('./session').then(()=> { sulla.create().then(client => start(client));
}).catch(err => { console.log(err) })
just fixed this