1 of 1 people found this helpful
I can confirm this issue. It occurred when communicating with a Psi client.
I submitted a pull request which adds a check in the parser on the value range. See
Thanks Anno for submitting the PR.
I've noticed that Spark has a similar issue (it doesn't trust the presence packet received by Smack):
int priority = presence.getPriority();
//Sometimes priority is not set in the presence packet received. Make sure priority is in valid range
priority = (priority < -128 || priority > 128) ? 1 : priority;
final Presence p = new Presence(presence.getType(), presence.getStatus(), priority, presence.getMode())
The Proposed modification got rejected:
Works as intended. If you don't want to trigger a reconnect, set an parsing exception handler. This of course, would mean that subsequent systems like Managers or the Roster will never see that particular presence stanza.
But this set me to a alternative solution by setting a ParsingExceptionCallback Function
Still the Presence message is ignored, but it does not result in a reconnect. It will still result in rooms where not all participants are visible.
Today, we've added Spark to our test environment, which doesn't disconnect and seems to ignore the faulty Presence stanza that's sent by Psi.
- Our Smack client
- Psi client
- Spark (Smack) client
- All three clients join the same chat room on Openfire
- Psi sends a message with wrong <priority> to the chat room
- Our Smack client will get disconnected -- user will no longer be allowed to join the room.
- Spark and Psi will continue but both users have a different view:
- Psi user will see 2 users in the chat room
- Spark user will see only 1 user -- but it can see messages sent from Psi.
For Spark the Psi user appears as "Ghost" user.
For the Openfire the Psi user doesn't appear as ghost user (XEP-0045: Multi-User Chat).
Does anyone have a suggestion?