Openfire (main)

• 

  Guus der Kinderen 4 days ago 078de05dfc1e3b6b54c225800c801d361d22a754

  OF-2814: Ensure that multi-byte characters in the XMPP data are parsed properly
  Prioer to this change, parsing errors occurred when multi-byte characters where provided to the parser byte-by-byte (or in byte arrays where a multi-byte character was split over more than one byte array).
  
  This commit re-introduces the fix for this problem that was created under OF-458. It uses a CharsetDecoder that will only read 'enough' bytes from an array, leaving bytes that form an incomplete character in the byte array (to be processed in the next iteration, when hopefully more data was added).
  
  The original fix is refactored a little to account for the different API that is provided by Netty (as compared to the old MINA based code), and to facilitate unit testing (of which a couple are added).
  
  (cherry picked from commit 3a32ce998f9c151c9fcb99951d3a1174fb9a8783)

  • xmppserver/src/main/java/org/jivesoftware/openfire/nio/NettyXMPPDecoder.java (version 078de05dfc1e3b6b54c225800c801d361d22a754)
  • xmppserver/src/main/java/org/jivesoftware/openfire/nio/XMLLightweightParser.java (version 078de05dfc1e3b6b54c225800c801d361d22a754)
  • xmppserver/src/test/java/org/jivesoftware/openfire/nio/XMLLightweightParserTest.java (version 078de05dfc1e3b6b54c225800c801d361d22a754)
• 

  Guus der Kinderen 5 days ago 05974548b0e98213cc21d41c1586da1a7850b794

  OF-2833: Fix serialization of User when date properties are null
  Since OF-2768, various 'date'-based properties of the User class are more likely to be null (especially in context of LDAP/AD).
  
  In this commit, a serialization issue is fixed that is triggered by these null-values.
  
  (cherry picked from commit 4daaf50e05dfd1b90f3749ab1a995e84e04dcc15)

  • xmppserver/src/main/java/org/jivesoftware/openfire/user/User.java (version 05974548b0e98213cc21d41c1586da1a7850b794)
• 

  Guus der Kinderen 5 days ago d2a8a61391974139848fbd498e283607606d4dde

  OF-2832: When merging data, handle null values
  When merging VCard data, if either the left-hand or right-hand side data is null, simply return the other bit. The code already did this in one direction, but now does it for the other direction too.
  
  This allows a VCard for a non-existing user to be set (which fixes setting avatars for MUC rooms).
  
  (cherry picked from commit 009019b7edc72a577b82f9f2b051a01ae3fcde89)

  • xmppserver/src/main/java/org/jivesoftware/openfire/ldap/LdapVCardProvider.java (version d2a8a61391974139848fbd498e283607606d4dde)
• 

  Guus der Kinderen 5 days ago e376d59d42b251eb7ed042e77816ee0f7ee533b1

  LDAP: reduce log verbosity when requesting data for unknown user.
  (cherry picked from commit 1a7c4fd96ba690e6005225fb8aaddaed10044d5b)

  • xmppserver/src/main/java/org/jivesoftware/openfire/ldap/LdapVCardProvider.java (version e376d59d42b251eb7ed042e77816ee0f7ee533b1)
• 

  Guus der Kinderen 5 days ago 0e7f16608c66b26662e5c9d10e6ceb6258a726e2

  OF-2827: JDBCAuthProvider should not lowercase/trim provided username
  By lowercasing the input, a username with a capital letter can't be used.
  
  The closely related JDBCUserProvider does not lowercase/trim values. It is probably best that both providers treat usernames in the same way.
  
  (cherry picked from commit 07ecd07ad87a2b09863cabdb6d02c05da261317c)

  • xmppserver/src/main/java/org/jivesoftware/openfire/auth/JDBCAuthProvider.java (version 0e7f16608c66b26662e5c9d10e6ceb6258a726e2)
• 

  Guus der Kinderen 5 days ago 2340ccae88db9fcc70e0b9534c8e5d5053533fa6

  Minor VCard improvements
  (cherry picked from commit 7c52305534bd493ce1a3054c7ad32153976b7716)

  • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQvCardHandler.java (version 2340ccae88db9fcc70e0b9534c8e5d5053533fa6)
• 

  Guus der Kinderen 5 days ago d97297f18c71d250d1d95999020a18562da9c373

  OF-2838: Return error when updating someone else's VCard
  Instead of silently ignoring such a request, return an error, as mandated by the XEP.
  
  (cherry picked from commit 00c88addd5fa8541b0318258bee4693d15d17142)

  • i18n/src/main/resources/openfire_i18n.properties (version d97297f18c71d250d1d95999020a18562da9c373)
  • i18n/src/main/resources/openfire_i18n_nl.properties (version d97297f18c71d250d1d95999020a18562da9c373)
  • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQvCardHandler.java (version d97297f18c71d250d1d95999020a18562da9c373)
• 

  Guus der Kinderen 5 days ago 2cb40fe48db80057f9851f98040dc1a30e18992e

  OF-2839: Return error when non-existing VCard is requested.
  When requesting a VCard from someone else, XEP-0054 (version 1.2) section 3.3 defines:
  
  > If no vCard exists [...] the server MUST return a stanza error,
  
  Furthermore:
  
  > If no vCard exists or the user does not exist, the server MUST return a stanza error, which SHOULD be either <service-unavailable/> or <item-not-found/> (but the server MUST return the same error condition in both cases to help prevent directory harvesting attacks).
  
  Finally, RFC 6121 section 8.5.1 defines:
  
  > If the user account identified by the 'to' attribute does not exist, how the stanza is processed depends on the stanza type. For an IQ stanza, the server MUST return a <service-unavailable/> stanza error to the sender.
  
  Openfire currently does not return an error, but an empty VCard. This is allowable when requesting one’s own VCard, but not when requesting that of others.
  
  Instead, Openfire must return an error with the service-unavailable condition when someone is requesting a VCard that doesn’t exist, from an existing user.
  
  Note that Openfire already returns service-unavailable when an IQ request is sent to a non-existing user.
  
  (cherry picked from commit 2759a5c642c799251cf6ce7115dae5aaefddb93f)

  • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQvCardHandler.java (version 2cb40fe48db80057f9851f98040dc1a30e18992e)
• 

  Guus der Kinderen 5 days ago 224b8365e37ba90d1146ffbe78b41bccdb57b06e

  Apply IDE suggestions
  Minor, non-functional changes suggested by the IDE (spelling, non-needed code, etc).
  
  (cherry picked from commit fcca17d42db26927113e4944b9658e5303bc15be)

  • xmppserver/src/main/java/org/jivesoftware/openfire/entitycaps/EntityCapabilitiesManager.java (version 224b8365e37ba90d1146ffbe78b41bccdb57b06e)
• 

  Guus der Kinderen 5 days ago 16dd6b57ec8cffd0968446d2377055b4667d0097

  OF-2835: Openfire should advertise CAPS support
  As Openfire supports CAPS (it calculates a hash for its own service discovery information), advertise support through service discovery.
  
  (cherry picked from commit b3f6919dd04afed190182e0807f89b68332f3983)

  • xmppserver/src/main/java/org/jivesoftware/openfire/entitycaps/EntityCapabilitiesManager.java (version 16dd6b57ec8cffd0968446d2377055b4667d0097)
• 

  Guus der Kinderen 5 days ago aede97a4a442385e023e58c30f49f91f32018ce0

  OF-2836: CapsManager should use provided algorithm
  Use the provided algorithm for entity capability calculation, rather than assuming that it's `SHA-1`.
  
  (cherry picked from commit 303369d0eb078bc4c5bd0e6e44bed0917ad3df80)

  • xmppserver/src/main/java/org/jivesoftware/openfire/entitycaps/EntityCapabilitiesManager.java (version aede97a4a442385e023e58c30f49f91f32018ce0)
• 

  Guus der Kinderen 5 days ago 8ecf3ca8c62bbc4253149a0fcf1922794973e15a

  OF-2825: Implement XEP-0030's security considerations
  Service Discovery's section 8 describes some security considerations that Openfire must implement.
  
  These security considerations partially contradict what's defined in RFC-6121 8.5.1. To allow for that implementation to be applied differently, this commit refactors the code to allow for an override of the original implementation of the 'no-such-user' handling.
  
  (cherry picked from commit 76b8b7f62f32bfbef8d7526b49324762678565c3)

  • xmppserver/src/main/java/org/jivesoftware/openfire/disco/IQDiscoInfoHandler.java (version 8ecf3ca8c62bbc4253149a0fcf1922794973e15a)
  • xmppserver/src/main/java/org/jivesoftware/openfire/disco/IQDiscoItemsHandler.java (version 8ecf3ca8c62bbc4253149a0fcf1922794973e15a)
  • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQHandler.java (version 8ecf3ca8c62bbc4253149a0fcf1922794973e15a)
• 

  Guus der Kinderen 5 days ago ffe079312932f762ea2542b68c72c0b91ccb1c72

  OF-2824: Annotate Session's address to be non-null
  Any Session's `address` property is expected to be non-null by the existing implementation. One notable exemption to this is `RemoteIncomingServerSession`, where the address _field_ is lazily initialized (and thus _can_ be null). Its getter value is guaranteed to be non-null though.
  
  This commit annotates and asserts that various Session address fields, getters and setters to have non-null values.
  
  The intention of this change is to simplify implementations (by dropping unneeded null-checks), more strictly document expected state (for easier maintenance) and introduce fail-fast behavior (that should help catch any current or future bugs).
  
  It is not expected that this change will introduce runtime changes (as the values already are non-null).
  
  (cherry picked from commit 417657b7e296a458bc140a760956a351c74c7c61)

  • xmppserver/src/main/java/org/jivesoftware/openfire/SessionManager.java (version ffe079312932f762ea2542b68c72c0b91ccb1c72)
  • xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalSession.java (version ffe079312932f762ea2542b68c72c0b91ccb1c72)
  • xmppserver/src/main/java/org/jivesoftware/openfire/session/RemoteIncomingServerSession.java (version ffe079312932f762ea2542b68c72c0b91ccb1c72)
  • xmppserver/src/main/java/org/jivesoftware/openfire/session/RemoteSession.java (version ffe079312932f762ea2542b68c72c0b91ccb1c72)
  • xmppserver/src/main/java/org/jivesoftware/openfire/session/Session.java (version ffe079312932f762ea2542b68c72c0b91ccb1c72)
• 

  Guus der Kinderen 5 days ago 4285ff6b334205797eabb62dc3c61306d5c68549

  Fixed a typo
  (cherry picked from commit 1e109775535b8c8c97d51843501cbec2ee8e95f9)

  • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 4285ff6b334205797eabb62dc3c61306d5c68549)
• 

  Guus der Kinderen 5 days ago 18f1ebd3b79db47cc124d44495a5f5ba220068dc

  OF-2824: Remove cluster-cache optimization
  It is suspected that, under race conditions, the optimization removed by this commit introduces data inconsistency.
  
  The optimization prevents modification of a second cache, as through the output of manipulation of the first cache it can be deduced that the second cache should already be in the expected state. By skipping manipulation of that second cache, a cluster-wide operation is prevented, which improves performance.
  
  The presence-based override for the optimization - one that I frankly do not understand - becomes obsolete by this change, and is also removed.
  
  The change introduced by this commit trades performance for more reliable data consistency. As an added benefit, the code becomes less complex, reducing maintenance costs.
  
  This commit changes the public signature of the `addClientRoute` method of `RoutingTable`: it no longer returns a value. The return value is currently not used by Openfire's own code. It was used for only two days, back in 2007: it was introduced in commit a940eeff4f72e4e9da70fcd0b4a1db1b3c40cd8d where it was used to update a statistic. This statistic got removed two days later, in commit 67f9ab65c36b8a38f5ab7c480415897839da21f0. Given the nature of the code (RoutingTable being _very_ low level), it is not expected that third-party code uses this method. It contract change should therefor be reasonably safe to do.
  
  (cherry picked from commit 3c7a0c684939ca5738868689360d22cb3583904a)

  • xmppserver/src/main/java/org/jivesoftware/openfire/RoutingTable.java (version 18f1ebd3b79db47cc124d44495a5f5ba220068dc)
  • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 18f1ebd3b79db47cc124d44495a5f5ba220068dc)
• 

  Guus der Kinderen 5 days ago 797b32c58401de65970fa77ae375885cb0abb0af

  OF-2824: Annotate ClientSession's address to be a _full_ JID
  Any Session's address is non-null, but _client_ sessions also are guarenteed to be full JIDs (in other words: they have a non-null resource part).
  
  This commit explicitly checks for this (to fail fast on any current and future bugs), and removes unneeded checks on usage. This intends to reduce code maintenance costs, by having less complex code.
  
  It is not expected that this change will introduce runtime changes (as the values already are full JIDs).
  
  (cherry picked from commit 4e0e4829dd0e299092664139bb23db6bf654240d)

  • xmppserver/src/main/java/org/jivesoftware/openfire/RoutingTable.java (version 797b32c58401de65970fa77ae375885cb0abb0af)
  • xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalClientSession.java (version 797b32c58401de65970fa77ae375885cb0abb0af)
  • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 797b32c58401de65970fa77ae375885cb0abb0af)
• 

  Guus der Kinderen 5 days ago 9465c1b7dbbe8ce97ad8cf0b1ade5fac76093f43

  OF-2824: Relax introduced fail-fast behavior
  In commit ef582e131f41bcb61bfb75c083986b92b0bcd002 fail-fast behavior was introduced that causes exceptions to be thrown when certain methods are invoked using a bare JID while the expected argument is a full JID.
  
  For certain lookups, these unexpected bare JIDs appear to be used all the time, causing Openfire to become pretty unusable.
  
  In this commit, the invocations that do not _modify_ cache content are short-circuited when a bare JID argument is used. This has the benefit of preventing the acquisition of a cluster-wide lock.
  
  (cherry picked from commit 30ab578e48227a8b2b7de165f690de980a8f528b)

  • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 9465c1b7dbbe8ce97ad8cf0b1ade5fac76093f43)
• 

  Guus der Kinderen 5 days ago f4680e76d05fc891922405aed0a6033a651bc58f

  Add code comment explaining re-entrant lock usage
  (cherry picked from commit 4570e79b926538fb137f8b1a00dff10b10f57b37)

  • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version f4680e76d05fc891922405aed0a6033a651bc58f)
• 

  Guus der Kinderen 5 days ago 590a5cc251e01f60369ab7405bb253d4d4f17b60

  OF-2824: Manipulation of client-related caches in RoutingTable using the same lock
  RoutingTableImpl has three closely related caches, that are used to represent the state of client session routes:
  - `usersSessionsCache`
  - `anonymousUsersCache`
  - `usersCache`
  
  Each value in the first cache is expected to correspond to a value in one of the other two caches.
  
  Under OF-2824, a bug is described where `usersCache` contains values that are _not_ in `usersSessionsCache`. That shouldn't be possible.
  
  Prior to this commit, manipulation of these caches is performed under a lock obtained from each of the caches. This means that the overall operation of adding an entry to `usersSessionsCache` and one of the other two caches is _not_ guarded by one singular lock (instead, two locks are used, each guarding the operation pertaining to that particular cache). This leaves room for a race-condition.
  
  This commit addresses the race condition by using one singular lock to guard manipulations in all of these caches.
  
  As all caches use a JID (in either bare or full form) as their key value, the singular lock introduced by this commit is based on the bare JID of the key that's being manipulated. This lock is obtained from the `usersSessionsCache`.
  
  This change can lead to more lock contention (as more operations are guarded by the same lock). Simultaneously, less acquiring of locks will take place (as many operations previously required two locks to be acquired, while now, only one is needed. What the effects are on performance is as of yet undetermined.
  
  This commit also introduces some related, minor changes:
  - Logged messages are made more consistent
  - Some operations have been moved outside of the protection of a (potentially cluster-wide) lock, to improve performance
  - Where methods expect to be called with a full JID, exceptions are thrown when a bare JID is used. This fail-fast behavior is intended to uncover any existing or future bugs.
  
  (cherry picked from commit 67108eddd2346099eab7cd4081286548c8bf3d70)

  • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 590a5cc251e01f60369ab7405bb253d4d4f17b60)