• FREE PRODUCTS, SPECIAL OFFERS & SUBSCRIPTION
    Find something worth grabbing
    Explore our free releases, check out current discounts, or join Eggy All Access from $14.99 a month or choose annual billing. Both options give you the same full access to all included current and future games, styles and products while your membership remains active.
  • Welcome to the Eggy Forums
    News, support, bug reports, feedback and community discussion for everything Eggy.
    Eggy News & Announcements Official releases, product updates, promotions, competitions and important Eggy news.
    General Discussion General community discussion, casual conversation and everyday topics across Eggy.
    Add-on Support Installation, configuration, upgrade and general support for Eggy products.
    Bug Reports Report reproducible bugs, errors and unexpected behaviour that needs investigating.
    Need support? Please include the product name and version, your XenForo version, what happened, and any relevant screenshots or server error logs. Providing clear details helps us investigate issues much faster.

Messenger Error

Having all permissions for our XF users set to YES for Messenger, one of our members keeps getting this error when trying to accept an invitation to accept an incoming friend request:

Messenger returned a invalid response (403)

This appears as a very brief popup, every time he attempts to click the Accept button in Messenger.

Any advice that could help fix this would be greatly appreciated.
 
Having all permissions for our XF users set to YES for Messenger, one of our members keeps getting this error when trying to accept an invitation to accept an incoming friend request:



This appears as a very brief popup, every time he attempts to click the Accept button in Messenger.

Any advice that could help fix this would be greatly appreciated.

Thanks for the additional information.

I've now specifically reproduced this response by testing the Messenger friend-request system with different XenForo permission configurations.

The exact "Messenger returned an invalid response (403)" response occurs when the affected account does not have the required effective Messenger permission. Restoring the required permission allows the same friend-request acceptance flow to work normally.

Messenger is therefore behaving as intended here: the friend-request action is permission protected and XenForo rejects the request when the visitor does not have the required effective permission.

If the permissions appear to be set to Yes in your ACP, I would recommend using XenForo's Analyze permissions function for the affected member specifically. Please also check every primary and secondary user group that account belongs to. We have encountered cases where looking at only one group's settings did not reflect the permissions the affected account was actually receiving.

If Analyze permissions confirms that the member has the required effective Messenger permissions but the 403 continues, the next things I would check would be their XenForo session/security token and any Cloudflare, ModSecurity or other WAF configuration. A page refresh is particularly worth trying if Cloudflare is in use, as a security re-verification can cause an existing AJAX request to receive a 403 until the page/session is refreshed.

At this point there is no indication of a fault in Messenger's friend-request handling itself. The same Accept flow works when the requesting account has the required effective permission, and the 403 can be reproduced by removing that permission.

If you can provide the affected member's XenForo Analyze permissions result, or the actual response body of the failed request from the browser Network tab, I can help interpret what XenForo or the server is rejecting.
 
That was super-helpful. Double-checking permissions via Analyze permissions showed me some results that had to be changed in order for that member to accept Friend requests. Odd that it was showing positive in the general permissions set for his usergroup, but I could have just been 'seeing things', haha. At any rate - thank you for that insight, hopefully it will get everything sorted for him, now!
 
Just a quick update - that did the trick - everything is now working as intended. I still have some questions about how to make the voice calling/video features work in Messenger - what is the best way to reach out to you for that, Eggy?
 
Just a quick update - that did the trick - everything is now working as intended. I still have some questions about how to make the voice calling/video features work in Messenger - what is the best way to reach out to you for that, Eggy?

Glad to hear everything else is working now.

For voice and video calls, most of the setup is already built into Messenger.

Go to Admin CP > Eggy Messenger > Settings and make sure Enable WebRTC voice calls and Enable WebRTC video calls are both switched on. You can also enable screen sharing there if you want it.

Next, check the XenForo user group permissions for the members who will be using Messenger. Under the Eggy Messenger permissions, make sure they are allowed to make calls and use video. If a member belongs to several user groups, it is worth checking their effective permissions as well.

Your site also needs to be running over HTTPS. Browsers will normally refuse microphone and camera access on an insecure site. The first time somebody starts or answers a call, their browser should ask for permission to use their microphone and, for a video call, their camera.

Under WebRTC connectivity you will see the server configuration. TURN relay is optional and is disabled by default. You can initially leave the WebRTC server configuration as:

[]
That allows Messenger to try a direct connection between the people in the call.

If calls ring correctly but the actual audio or video will not connect for certain users, especially when they are on different networks, mobile data, company networks or restrictive routers, that is normally where STUN/TURN comes in.

STUN helps the two browsers establish a direct connection. TURN goes a step further and relays the media when a direct connection is not possible. Messenger supports both, including coturn with temporary credentials, but I would only worry about setting up TURN if you actually need it.

The Node.js realtime server is also recommended if you are using it. Calls can fall back to Messenger's AJAX system, but realtime gives much faster signalling for ringing, answering and exchanging the WebRTC connection information.

So for the first test I would do this:
  1. Enable voice and video calls in Messenger settings.
  2. Check the Messenger call/video user group permissions.
  3. Make sure the site is HTTPS.
  4. Leave TURN disabled initially.
  5. Test between two different accounts, preferably on two different devices.
  6. Allow microphone/camera access when the browser asks.
  7. If the call rings but never properly connects, then we can look at adding STUN or setting up TURN for your server.
There is also Eggy Messenger > Diagnostics in the Admin CP which will check the Messenger installation, realtime gateway and whether TURN has been configured correctly if you enable it.

If you get as far as the call ringing but have no audio/video, let me know exactly what happens at that point and we can go through the WebRTC side from there.
 
Followed the setup steps you have outlined. Tried testing, but my side always showed the word "Calling" but never properly connected? The other side showed as "Connected". Further to that, I have the following showing in Diagnostics:

Node.js realtime gatewayAttentionNode.js gateway is not reachable at http://127.0.0.1:31337.
 
Thanks, that helps narrow it down.

The Node.js message in Diagnostics simply means Messenger has been set to use the realtime gateway, but nothing is currently responding on 127.0.0.1:31337.

When Node.js is installed and the Messenger realtime service is actually running, it keeps a live connection open between the browser and the server. That lets things like call ringing, answering and connection updates happen immediately instead of waiting on the AJAX fallback.

So the Node.js warning itself isn't an issue with Messenger. If realtime is enabled, the Node service also needs to be installed, running and reachable on the configured port.

That said, Messenger is also supposed to work without Node.js by falling back to AJAX.

The useful part of your test is that one side is showing "Connected" while the caller stays on "Calling". I've traced that behaviour and there is an issue in the AJAX fallback for calls where the caller is not picking up the updated call state correctly after the other person accepts.

So I wouldn't change your TURN or STUN settings at this stage. The WebRTC connection is getting far enough for the receiving side to accept the call, and the part I need to correct is the fallback call status handling on the caller's side.

I'll get that corrected.
 
I’ve released Messenger 1.1.1e with a fix for the call state issue you were seeing when Messenger falls back to AJAX instead of using the Node.js realtime gateway. Please download and install 1.1.1e, then test a voice or video call again between two accounts.

The main thing to check is that once the other person answers, both sides move from “Calling” to “Connected” properly and the call continues normally. If possible, also test with the Node.js gateway still unavailable so we can confirm the AJAX fallback is now handling the call correctly.

The Node.js diagnostic warning itself will still show until the optional realtime service is installed and running, but Messenger should now fall back correctly without that preventing the call state from updating.
 
Back
Top