[iFixRobots]

Cause

On logout the bridge only drops its local state. The Messenger web session behind the cookies stays alive, and with it the bridge's encrypted chat device. Every logout therefore leaves a dead device on the account that every encrypted message to the user is still encrypted for.

Change

For cookie-based Messenger logins (messenger mode), LogoutRemote now ends the web session with the same request messenger.com sends when you log out, then deletes the local device store as before. Logging out the Facebook session also logs out the encrypted chat session, so no separate device removal is needed.

• The request uses the existing messagix HTTP client, after the socket is disconnected, with a 10 s timeout that doesn't inherit the provisioning request's cancellation. Errors are only logged.
• messenger.com's request (openMessengerLogOut / MessengerLogoutHandler.react) is a form POST to XMessengerDotComLogoutController (/logout/) with fb_dtsg and jazoest (DTSGUtils.getNumericValue of the token). The bridge sends POST https://www.messenger.com/logout/, application/x-www-form-urlencoded, body fb_dtsg=<token>&jazoest=<page jazoest>, with the session cookies, without following the redirect.
• Unchanged: Messenger Lite (token login) and facebook.com cookie logins. Their logout request isn't in the captured messenger.com client, so they keep today's behaviour. Instagram uses igconnector and isn't affected.
• Behaviour note: self-hosters who copied cookies from their own browser will be signed out of messenger.com there when they log out of the bridge.

Testing

No live before/after was run on this version; no test account was available. The evidence that the encrypted chat device goes away with the session is Tulir's statement on tulir/whatsmeow#1341.

Offline, against a local test server:

Case	Result
Request	POST /logout/, form content type, Referer/Origin https://www.messenger.com, cookies sent, body fb_dtsg=…&jazoest=…; 302 accepted
Server never answers	returns after 10 s with context deadline exceeded, logged
500 / no fb_dtsg loaded	error returned and logged, logout continues

Earlier versions of this PR removed the device directly through whatsmeow and were tested live. With the request sent directly, the account's device list went from 12 to 11 and the bridge's device was removed. That code is no longer in the PR.

Tag @indent to continue the conversation here.

[indent]

Issues

All clear! No issues remaining. 🎉

4 issues already resolved

• The E2EE client is always created with MessengerConfig set, and the pinned whatsmeow's Client.Logout returns "can't logout with Messenger credentials" before sending any IQ. Every logout detaches handlers, logs "Failed to remove encrypted chat device", and leaves the device registered with Meta. (fixed by commit 78aad35)
  _{Found by Indent Review Agent}
• removeE2EEDevice is gone at this head and nothing in the branch sends a device-removal request. LogoutRemote still disconnects and deletes the local WADevice as on main, so Meta keeps the device registered, while the title and description say it calls whatsmeow's Logout. (fixed by commit 8753ab2)
  _{Found by Indent Review Agent}
• logoutMetaSession POSTs to messenger.com/logout/ with the bridge's stored cookies. For cookie-paste logins that is the user's own browser session, so bridge logout also signs them out of messenger.com. Main never touched the remote web session and the description says it isn't ended. (fixed by commit 8753ab2)
  _{Found by Indent Review Agent}
• cli.GetHTTP().GetNewProxy = nil is an unlocked write while other goroutines may still use the same HTTPClient; UpdateProxy and changeProxyAfter check it non-nil and then call it, so clearing it between the check and the call is a nil-func panic. (fixed by commit 8753ab2)
  _{Found by Indent Review Agent}

CI Checks

All required CI checks passed on 8753ab2.

Review agents

Select any unchecked box below to run or rerun that agent.

Passed (1)

• Indent Review Agent · No bugs; failed logout can still rotate proxy

Full results

Indent Review Agent

• Summary: No bugs; failed logout can still rotate proxy
• Last ran on commit: 8753ab23
• Latest result

  {
    "summary": "No bugs; failed logout can still rotate proxy",
    "findings": [
      {
        "fix": "Change the description, or give the logout request a way to skip proxy rotation that doesn't mutate the shared client, such as a per-request flag or a copied HTTPClient whose GetNewProxy is nil.",
        "line": 92,
        "path": "pkg/messagix/facebook.go",
        "issue": "Now that the GetNewProxy = nil line is gone, the client keeps the GetNewProxy set at connect (pkg/connector/client.go:281). MakeRequestOnceNoRedirect goes through makeRequestOnce, which calls c.UpdateProxy(\"http request error: ...\") on any transport error (httpclient/http.go:643). If the /logout/ POST times out or the connection fails, getProxy runs, and when get_proxy_from is configured that means an extra request to the proxy provider, all for a client that is about to be thrown away. Nothing breaks: the error is still returned and logged, and the race from the earlier revision is gone. But the description's \"no proxy rotation\" claim is wrong.",
        "title": "A failed logout request still rotates the proxy, despite the description saying it doesn't",
        "severity": "nit"
      }
    ]
  }

[tulir]

As mentioned in tulir/whatsmeow#1341, just logging out the facebook session might be better, which will automatically log out the whatsapp session