Best auth method

[real rover]

I'm having trouble storing the user's session. I'm currently storing the session for Firebase and many sessions are being very large, taking up a lot of CPU in the container I have on AWS. What session persistence solution do you usually use?

[hollow coyote]

LocalAuth

[oak pewter]

@hollow coyote Wouldn't local auth make it hard to scale since horizontally since the machine/instance would be stateful? You could always set a load balancer to for user stickiness on a certain machine, but that would add to the complexity of the infra.

Of course, that would only be an issue if you're offering the service to multiple users.

@real rover I'm still in development for my WhatsApp Web bot, and I'm gonna be storing sessions on AWS S3. Would update you on how it goes for me.

[hollow coyote]

I think you didn't understand how the project works, at the end everything is local

[oak pewter]

Well, a browser is local, the WhatsApp web app is opened locally but you could always store the session in S3 and fetch it elsewhere, couldn't you? This would better enable scaling to multiple machines to handle message sending and authentication if you need the volume? Where am I wrong? Would appreciate your notes.

[hollow coyote]

RemoteAth is only a backup

to work everything needs to be local

[oak pewter]

That is not how it's presented in the guide/docs though. Nonetheless, if I understand correctly, scaling to multiple machines would not work that simply? Unless the backed up sessions are fetched in the machine beforehand?

[hollow coyote]

Session is related to a browser and machine, I don't think you can scale it to multiples machines using the same session

RemoteAuth is useful to stateless machine, docker, where doesn't exist a persistent volume, but the browser and the machine will keep the same

I don't use it, but you can create your own tests

[oak pewter]

Well sure, but can't (all) the machines fetch all the sessions and now you have them available globally in your cluster? Wouldn't that make it possbile to scal? Alternatively, implementing something like on demand fetching for the session could also achieve the same objective, wouldn't it?

[hollow coyote]

In this case, you can use some variation of RemoteAuth

Or create your own

[oak pewter]

Ok, I'll be continuing with this approach and see how it goes. I'll keep you updated if you're interested.

[near wasp]

I am very interested in hearing the update of how it went

[oak pewter]

I'm still working on it, facing some issues here and there, but will update you on this thread if it works or not, for sure.

[tight plume]

you guys can try my fork RemoteAuth for mongodb is working fine

https://github.com/ayusc/whatsapp-web.js

[tight plume]

tell me if it works for you
on first time it will authenticate immediately
but from second on it needs some time to authenticate because of the new algorithm

[oak pewter]

@tight plume I haven't checked out your repo yet, but I managed to make remote auth work successfully with multiple machines. The documentation is almost enough to get it to work, but there's catch. There's an event called remote_session_saved which in my case, I need to listen to, seems like the initial call of saving the remote session does not get called at all, not sure why, and the event never gets emitted. I needed to dive into the repo's code to figure out how to manually force it to save the session on S3, and I used the following:

client.on('ready', () => {
  setTimeout(() => {
    client.options.authStrategy.storeRemoteSession({ emit: true });
  }, 60000);
});

In my case, I persist the WhatsApp auth status in my app, showing the user the option to either connect their WhatsApp account or disconnect it, and I show the QR code in my UI. If you're interested in the details of how I'm doing this, I'd be happy to explain. Other than that, it's pretty straight forward, just follow the documentation, create a client for each session as per the docs (you'd have to use remote auth here instead, this is just the example from the docs):

const { Client, LocalAuth } = require('whatsapp-web.js');

const client1 = new Client({
    authStrategy: new LocalAuth({
    clientId: "client-one" })
});

const client2 = new Client({
    authStrategy: new LocalAuth({
    clientId: "client-two" })
});

Assuming this happened in machine/server 1, with client id "client-one", trying to instantiate a new client with the client id "client-one" but in machine/server 2, would try to fetch any existing session for this user from the remote store.

@near wasp
@kind wasp

If you need any extra details, or would like me to help you in any specifics, please don't hesitate to ask.

[near wasp]

Wow, thank you very much.

[oak pewter]

@near wasp Did you achieve any progress implementing this?