Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
In non-anonymous rooms, participants can/should see the others' real JID. That's usually done via presences. However, according to XEP-0045, section 7.2.13 a server MAY send the real JID also as an "addresses" stanza with type "ofrom" within the message.
This PR implements that. I opted to add the field if {{canAnyoneDiscoverJID}} is set to true for the room. Ofc, a more sophisticated implementation might include other cases based on the participant's role.
Testing
I wanted to write some tests for this, but {{LocalMUCRoom}} had some difficult to mock dependencies to singleton classes (namely the {{MUCPersistenceManager}} that is used in the constructor).
Upon closer inspection, I wonder if the provided fix is quite correct. The XEP mentions that this attribute can be added to messages, but specifies this only when messages are sent as part of message archive (the attribute is not defined for ‘live’ messsages).
For live messages, the real JID can be discovered via presence information that was already sent by occupants joining the room.
I’m thinking that adding ‘ofrom’ to all messages, as was done by this fix, is at best redundant. I’m not sure if this introduces (privacy/security?) issues.
https://github.com/igniterealtime/Openfire/pull/1711
Introduction
In non-anonymous rooms, participants can/should see the others' real JID. That's usually done via presences. However, according to XEP-0045, section 7.2.13 a server MAY send the real JID also as an "addresses" stanza with type "ofrom" within the message.
This PR implements that. I opted to add the field if {{canAnyoneDiscoverJID}} is set to true for the room. Ofc, a more sophisticated implementation might include other cases based on the participant's role.
Testing
I wanted to write some tests for this, but {{LocalMUCRoom}} had some difficult to mock dependencies to singleton classes (namely the {{MUCPersistenceManager}} that is used in the constructor).