Store RemoteAuth ZIP files inside dataPath

[vedantmgoyal9]

PR Details

Fixes read-only filesystem error on AWS Lambda.

Description

When deploying on AWS Lambda, the filesystem is read-only, with /tmp only being writable. This causes error while using LocalAuth or RemoteAuth strategy. This PR fixes it by detecting the runtime environment is AWS Lambda, and use /tmp/wwebjs_auth and /tmp/wwebjs_cache directories, instead of ./.wwebjs_auth and ./.wwebjs_cache.

Although, we could partially fix the issue by using the below config, there is no way to tell the library, a custom path for where to store ZIP files when using RemoteAuth strategy.

const client = new Client({
  authStrategy: new RemoteAuth({
    store: ... , // store
    dataPath: '/tmp/wwebjs_auth', // <- use /tmp
    backupSyncIntervalMs: 120000,
  }),
  webVersionCache: {
    type: 'local',
    path: '/tmp/wwebjs_cache', // <- use /tmp
  },
  puppeteer: ... // puppeteer config
});

Another possible way to fix this issue is to create RemoteAuth ZIP files inside wwebjs_auth directory itself, instead of current working directory. This could be a better way to handle this issue instead of adding environment-specific workarounds to the library itself.

Related Issue(s)

N/A

Motivation and Context

Enables to run whatsapp-web.js on AWS Lambda with zero-config.

How Has This Been Tested

Tested manually.

• https://github.com/vedantmgoyal9/vedantmgoyal9/blob/main/package.json
• https://github.com/vedantmgoyal9/vedantmgoyal9/blob/main/api/wa-send-msg.ts

Environment

• Machine OS: AWS Lambda
• Phone OS: Android
• Library Version: 1.26.0 + this commit
• WhatsApp Web Version: Latest
• Browser Type and Version: Chromium 131 from https://github.com/Sparticuz/chromium/releases
• Node Version: Node20

Types of changes

• Dependency change
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• [N/A] I have updated the documentation accordingly (index.d.ts).
• [N/A] I have updated the usage example accordingly (example.js)

[msgadi]

@vedantmgoyal9 Storing session or authentication-related data in the /tmp ephemeral storage of AWS Lambda is not recommended. Since the data in /tmp is specific to an instance of a Lambda execution environment, it is not guaranteed to persist across multiple invocations. This could lead to inconsistencies or loss of critical data.

A more reliable approach is to leverage AWS S3 for storing such data. S3 provides persistent, scalable, and secure storage, making it an excellent choice for managing session or authentication-related information. You can explore an example implementation using S3 for authentication here: Remote Auth Strategy Using S3.

[vedantmgoyal9]

Yes, I know that. I store sessions in Firebase Storage, but when "restoring" the session, the library writes to current working directory which is read-only. I have patched it to use /tmp while downloading and decompressing the ZIP file so it does not fail.

[tuyuribr]

Why not just include one 'remoteSessionPath' that works like dataPath ?

The function 'isRunningInAwsLambda' wont go to production, convert it to an option or make the remoteSessionZipPath to fix your problems

[vedantmgoyal9]

@tuyuribr I think I have solved the issue without adding another option. It would store ZIP files inside the dataPath instead of the current working directory.

const client = new Client({
  authStrategy: new RemoteAuth({
    store: ... , // store
    // use /tmp, and since ZIP files will be stored inside dataPath, it resolves the issue
    dataPath: '/tmp/wwebjs_auth',
    backupSyncIntervalMs: 120000,
  }),
  ... // other config
});

[vedantmgoyal9]

hello @tuyuribr, any updates?