mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-03 12:23:08 +00:00
db52ad0f07
The opt-in WHATSAPP_FORWARD_OWNER_MESSAGES path in bot mode marks
fromMe inbound messages as fromOwner: true and forwards them to the
Python adapter so plugins can detect "owner just typed in this chat"
and trigger handover / sliding TTL flows. The previous implementation
bypassed the allowlist for that path: the existing allowlist gate at
the bottom of the dispatch loop is guarded by !msg.key.fromMe, so any
chat the operator happened to reply to was forwarded — even ones not
on WHATSAPP_ALLOWED_USERS.
Concretely, on a deployment with a single allowlisted customer, an
owner reply in any other chat would still wake Hermes and let the
gateway-policy plugin's owner-implicit branch create a stray handover
row keyed by the non-allowlisted chatId.
Fix: extract the bot-mode fromMe gate into a small pure helper
(`owner_message_gate.js`) that returns one of
{drop_echo, drop_disabled, drop_allowlist, forward_owner, pass} so the
new allowlist branch can be unit-tested without spinning up Baileys.
The check runs against the customer chatId (not senderId, which is
the owner's own number/LID and won't be on the allowlist by
construction). matchesAllowedUser already short-circuits true on an
empty allowlist or "*", so deployments without an allowlist see no
behavior change.
Self-chat mode is untouched — its existing isSelfChat pin is the
correct guard there.
Tests: scripts/whatsapp-bridge/owner_message_gate.test.mjs covers
echo drop, disabled drop, the new allowlist drop, the forward path,
the open-allowlist short-circuit, and the precedence of echo/disabled
checks over the allowlist check (so logs stay honest).
56 lines
2.1 KiB
JavaScript
56 lines
2.1 KiB
JavaScript
/**
|
|
* Pure classifier for the WhatsApp bridge's bot-mode dispatch loop.
|
|
*
|
|
* Centralises the "should this fromMe message be forwarded as fromOwner?"
|
|
* decision so the gate can be unit-tested without spinning up Baileys or
|
|
* the Express server.
|
|
*
|
|
* Lives next to `outbound_ids.js` rather than inline in `bridge.js`
|
|
* because the previous implementation accidentally bypassed the
|
|
* customer-side allowlist when forwarding owner-typed messages — see
|
|
* the regression test in `owner_message_gate.test.mjs`.
|
|
*
|
|
* Caller responsibilities:
|
|
* - Only invoke in bot mode. Self-chat mode has its own self-chat
|
|
* pinning logic and must not delegate here.
|
|
* - Pre-filter group / status JIDs (the gate doesn't know about them).
|
|
* - On `drop_allowlist`, log the rejection so operators can audit
|
|
* accidental allowlist mismatches.
|
|
*
|
|
* Returned actions:
|
|
* - 'pass' : non-fromMe, fall through to existing handling
|
|
* - 'drop_echo' : fromMe and matches a recently-sent /send id
|
|
* - 'drop_disabled' : fromMe but operator hasn't opted into forwarding
|
|
* - 'drop_allowlist' : fromMe and the *customer chatId* isn't on the
|
|
* allowlist (owner-typed reply to a stranger)
|
|
* - 'forward_owner' : fromMe, owner-typed, allowlisted — forward with
|
|
* fromOwner: true
|
|
*/
|
|
|
|
export function classifyOwnerMessageGate({
|
|
fromMe,
|
|
fromOwnerEnabled,
|
|
recentlySent,
|
|
allowlistMatches,
|
|
messageId,
|
|
chatId,
|
|
}) {
|
|
if (!fromMe) {
|
|
return { action: 'pass' };
|
|
}
|
|
if (recentlySent && recentlySent.has(messageId)) {
|
|
return { action: 'drop_echo' };
|
|
}
|
|
if (!fromOwnerEnabled) {
|
|
return { action: 'drop_disabled' };
|
|
}
|
|
// Allowlist gate: check the *customer* chatId, not the sender. The
|
|
// sender is the owner's own number/LID and won't be on the allowlist
|
|
// by construction. Without this check, any contact the owner happens
|
|
// to reply to leaks into Hermes and triggers implicit handover in the
|
|
// gateway-policy plugin.
|
|
if (typeof allowlistMatches === 'function' && !allowlistMatches(chatId)) {
|
|
return { action: 'drop_allowlist' };
|
|
}
|
|
return { action: 'forward_owner' };
|
|
}
|