whalibmob 5.16.0 → 5.17.0

package/README.md

@@ -9,6 +9,8 @@
 
 CONTACT ME ON TELEGRAM  IF YOU WANT TO WORK WITH ME AND IF YOU HAVE PROBLEM WITH WHALIBMOB : @brtyu545
 
+**Need test numbers to try whalibmob with?** Message me on Telegram at **@brtyu545** — I can provide phone numbers for receiving SMS verification codes, so you can register and test whalibmob without using your own number.
+
 If you want News about whalibmob enter this whalibmob channel: https://t.me/+sHN4MDCyB7U5OWY0
 
 
@@ -2005,6 +2007,7 @@ Every option is optional; `sessionDir` is the only one most senders ever set.
 | `sessionDir` | `~/.waSession` | The authentication folder. Each number gets its own subfolder inside it — see [Saving & Restoring Sessions](#saving--restoring-sessions). |
 | `autoFixNumber` | `true` | Re-file the session automatically when the server reports the account under a different number. Set `false` to be told instead of fixed — see [The Number WhatsApp Files Your Account Under](#the-number-whatsapp-files-your-account-under). |
 | `autoRead` | `true` | Send read receipts for incoming messages. `false` leaves them unread. |
+| `refreshVersion` | `true` | **iOS sessions only.** Check the App Store for the current build on every `init()` and write it into the session file. Set `false` to keep announcing whatever the session registered with — see [Keeping the Announced Version Current](#keeping-the-announced-version-current). Android is unaffected either way. |
 | `pino` | off | Debug logging. `true` turns it on at `debug` level; an object is passed to `pino` as-is. |
 | `sentCacheSize` | `2000` | How many sent messages keep their plaintext so a retry receipt naming them can be answered. |
 | `maxRetryResends` | `5` | How many times one message may be re-sent in answer to retry receipts before the client gives up. |
@@ -2571,6 +2574,60 @@ of a pile by prefix.
 > is moved unless you ask — `wa migrate-sessions` does that, one number or all
 > of them, and re-running it is safe.
 
+### Keeping the Announced Version Current
+
+Every connection announces the WhatsApp build it claims to be. The server checks
+it, and when it stops recognising the number it refuses the handshake with
+`405` — a failure that says nothing about the version and has nothing to do with
+the account.
+
+A session records the version it registered with. Left alone it announces that
+same number forever, so a number registered in spring is still claiming a spring
+build in autumn, and one day the connect simply stops working.
+
+**iOS sessions now refresh themselves.** On every `init()` the client asks the
+App Store what the current build is and writes it into `<phone>.json` before the
+handshake. Nothing to run, nothing to remember:
+
+```js
+client.on('version_update', ({ from, to }) => {
+  console.log('announcing', to, 'instead of', from)
+})
+
+await client.init('40756469325')
+```
+
+Three rules keep this from being the thing that breaks a working session:
+
+- **It never goes backwards.** The App Store lookup answers with a pinned
+  fallback rather than failing when it cannot reach the network, and that
+  fallback can easily be older than what the session holds. Moving a session to
+  an older version is the one outcome that makes a `405` *more* likely.
+- **`WA_VERSION` still wins.** A version pinned on the way out of a `405` is a
+  decision, and is never quietly replaced.
+- **A failed lookup changes nothing.** The session keeps the version it has and
+  the connect carries on.
+
+Set `{ refreshVersion: false }` on the client to turn it off.
+
+> [!NOTE]
+> **Android is deliberately left alone.** Its version comes out of the APK the
+> token material was read from, and the two have to agree — the registration
+> token is computed from that build. Refreshing the announced version behind the
+> caller's back would put it out of step with the token. Android keeps the
+> explicit flow: `wa apk-material --download`, then `wa refresh-version`.
+
+The manual tool still works on both platforms, and is the only way to move an
+Android session:
+
+```bash
+wa refresh-version 40756469325                    # current build for the platform
+wa refresh-version 40756469325 --version 2.25.1.2 # or one you name
+```
+
+Companion sessions have never had this problem: `connectWeb()` reads the live
+web revision on every connect already.
+
 ### One-time Pre-keys
 
 A pre-key is a one-shot Diffie-Hellman key the account leaves with the server so

package/lib/Client.js

@@ -379,6 +379,13 @@ class WhalibmobClient extends EventEmitter {
     // automatically on the first refused login. Set { autoFixNumber: false } to
     // be told about it instead.
     this._autoFixNumber  = opts.autoFixNumber !== false;
+    // An iOS session checks the App Store for the current build on every
+    // connect and writes it back — see _refreshIosVersion(). Set
+    // { refreshVersion: false } to keep announcing whatever the session
+    // registered with. Android is not affected either way: its version comes
+    // out of the APK the token material was read from, and that stays a
+    // deliberate step.
+    this._refreshVersion = opts.refreshVersion !== false;
     this._numberFixAttempted = false;
     this._pingTimer               = null;
     this._keepTimer               = null;
@@ -497,6 +504,67 @@ class WhalibmobClient extends EventEmitter {
     return this.init(phoneNumber);
   }
 
+  /**
+   * Bring an iOS session's announced version up to date, on every connect.
+   *
+   * A session records the version it registered with and announces that
+   * forever after. Months later the server stops accepting it and the connect
+   * is refused with a 405 that says nothing about why — and the only remaining
+   * move, before this, was to run `wa refresh-version` by hand or register the
+   * number again. The companion path never had that problem because
+   * connectWeb() reads the live revision every time; this is the same idea for
+   * the primary one.
+   *
+   * iOS only, and deliberately so. Android's version comes out of the APK the
+   * token material was read from — the two have to agree, because the token is
+   * computed from that build — so refreshing it behind the caller's back would
+   * put the announced version and the token out of step. Android keeps its
+   * Play Store flow exactly as it was.
+   *
+   * Three rules keep this from being the thing that breaks a working session:
+   *
+   *   • It never goes backwards. fetchIosVersion() answers with the pinned
+   *     fallback rather than failing when the lookup does not work, and that
+   *     fallback can easily be older than what a session already holds. Moving
+   *     a session to an older version is the one outcome that makes a 405 more
+   *     likely rather than less.
+   *   • WA_VERSION still wins. Someone who has pinned a version on the way out
+   *     of a 405 must not have it quietly replaced.
+   *   • It never throws, and it never blocks for long. A lookup that fails
+   *     leaves the session exactly as it was and the connect carries on.
+   */
+  async _refreshIosVersion() {
+    if (!this._refreshVersion || this._mode === 'web' || !this._store) return;
+    if (process.env.WA_VERSION) {
+      _whaDbg('[DBG] VERSION refresh skipped — WA_VERSION is set');
+      return;
+    }
+
+    const device = this._store.device || getDeviceConfig();
+    if (device.os === 'android') return;   // the APK flow owns this
+
+    try {
+      const { compareVersions } = require('./Registration');
+      const before = this._store.version;
+      const live   = await fetchIosVersion(!!device.business);
+      if (!live) return;
+
+      if (before && compareVersions(live, before) <= 0) {
+        _whaDbg('[DBG] VERSION already current (' + before + ', App Store says ' + live + ')');
+        return;
+      }
+
+      this._store.version = live;
+      this._persistStore();
+      _whaDbg('[DBG] VERSION refreshed ' + (before || 'none') + ' → ' + live +
+        ' (App Store listing)');
+      this.emit('version_update', { from: before || null, to: live, source: 'App Store listing' });
+    } catch (err) {
+      // A session that cannot ask keeps the version it has.
+      _whaDbg('[DBG] VERSION refresh failed: ' + (err && err.message));
+    }
+  }
+
   async init(phoneNumber) {
     phoneNumber = String(phoneNumber).replace(/\D/g, '');
     this._phoneNumber = phoneNumber;
@@ -526,6 +594,10 @@ class WhalibmobClient extends EventEmitter {
       );
     }
 
+    // Before the handshake, which reads the version straight out of the store.
+    // iOS only; Android keeps its APK flow. See _refreshIosVersion().
+    await this._refreshIosVersion();
+
     const signalFile  = path.join(this._sessionDir, `${phoneNumber}.signal.json`);
     const skFile      = path.join(this._sessionDir, `${phoneNumber}.sk.json`);
     const tcTokenFile = path.join(this._sessionDir, `${phoneNumber}.tctoken.json`);

package/lib/Registration.js

@@ -2137,7 +2137,7 @@ async function verifyCode(store, code, opts) {
   throw new Error(`Verification failed: ${reason || JSON.stringify(result)}`);
 }
 
-module.exports = { checkIfRegistered, checkNumberStatus, requestSmsCode, verifyCode, fetchIosVersion, fetchAndroidVersion, fetchWaVersion, currentVersionFor, refreshSessionVersion, parsePhone, getCountryMeta, assertRegistrationKeys, parseSocksProxy, socksProxyUrl };
+module.exports = { checkIfRegistered, checkNumberStatus, requestSmsCode, verifyCode, fetchIosVersion, fetchAndroidVersion, fetchWaVersion, currentVersionFor, refreshSessionVersion, compareVersions, parsePhone, getCountryMeta, assertRegistrationKeys, parseSocksProxy, socksProxyUrl };
 
 // The HTTP reader, exposed for tests. Not part of the public API.
 module.exports._http = { readHttpResponse, parseHttpResponse, decodeChunkedBody };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "whalibmob",
-  "version": "5.16.0",
+  "version": "5.17.0",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API and web ",
   "author": "Kunboruto20",
   "main": "index.js",