And another problem. I want only subscribers to be visible in the general chat room, but guests are also visible. Moreover, even though I delete all participants, after a while the entire list is filled with old participants again.
Hello,
This error message means WordPress itself rejected the request’s security token (REST nonce) — Better Messages never even got the chance to check the guest’s authorization.
In practice this is nearly always caused by a page-caching plugin or server-level cache serving visitors HTML that is older than the WordPress nonce lifetime (12–24 hours), or serving a page that was cached under a different login context.
Could you tell me which caching / optimization / security plugins are active on your site (or any hosting-level cache or firewall like Cloudflare, LiteSpeed, WP Rocket)?
As a workaround: exclude the pages containing chat rooms from full-page caching, or set the cache lifetime below 12 hours.
Regarding participants reappearing after you delete them: that is the “Auto join” / “Auto add” feature working as designed — room membership is continuously reconciled, so manual deletion is always undone. To keep specific people out, ban them inside the chat room (bans are respected by auto add), or disable auto join and use “Auto exclude” together with a restricted “Who can join” list.
For a subscribers-only room: set “Who can join” to Subscriber, disable guest access for that room, and enable “Only joined users can read messages” — otherwise anyone who can open the page can still read the messages.
Thanks!
LiteSpeed plugin is active. I disabled cache for the page, but the problem persists. Sometimes it works, sometimes it doesn’t; I don’t understand why.
wp-json/better-messages/v1/thread/12?nocache=1783409252816 wp-json/better-messages/v1/chat/29181/join?nocache=1783409254069 wp-json/better-messages/v1/chat/29181/join?nocache=1783409254069 wp-json/better-messages/v1/checkNew?nocache=1783409267204
Many things like this give a 403 forbidden error.
The problem was related to .htaccess; it was fixed after installing the default settings.
I don’t understand why this is caused by the LiteSpeed Cache plugin. The system works when I disable the plugin, but how do I use it with the cache enabled?
-
This reply was modified 1 week, 1 day ago by
pablito201.
marker LOGIN COOKIE start
RewriteRule .? – [E=”Cache-Vary:,wp-postpass_94f1a9c56161f3a3491ef5374a6bb13a”] marker LOGIN COOKIE end
This code is causing the problem, but it’s reapplied when LiteSpeed saves the settings.
Hello,
Thanks for the details.
LiteSpeed caches pages on the server level. The chat page contains a WordPress security token which is valid only for 12-24 hours, so when LiteSpeed serves an old cached copy of the page, WordPress rejects all chat requests with this error. That Cache-Vary line is added by LiteSpeed Cache itself, so it will always come back after saving its settings – it is not something broken in your .htaccess.
If you want to keep LiteSpeed enabled, exclude pages with chat from caching in LiteSpeed Cache settings and do “Purge All” after that.
I will also try to improve guest handling in one of the next updates.
