Build: #2074 did not complete Scheduled with changes by Guus der Kinderen

Stages & jobs

  1. Build and Package

  2. Copy to Website

Code commits

Openfire (master)

  • Guus der Kinderen

    Guus der Kinderen 3a32ce998f9c151c9fcb99951d3a1174fb9a8783

    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).

    • xmppserver/src/main/java/org/jivesoftware/openfire/nio/NettyXMPPDecoder.java (version 3a32ce998f9c151c9fcb99951d3a1174fb9a8783)
    • xmppserver/src/main/java/org/jivesoftware/openfire/nio/XMLLightweightParser.java (version 3a32ce998f9c151c9fcb99951d3a1174fb9a8783)
    • xmppserver/src/test/java/org/jivesoftware/openfire/nio/XMLLightweightParserTest.java (version 3a32ce998f9c151c9fcb99951d3a1174fb9a8783)
  • Guus der Kinderen

    Guus der Kinderen 4daaf50e05dfd1b90f3749ab1a995e84e04dcc15

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/user/User.java (version 4daaf50e05dfd1b90f3749ab1a995e84e04dcc15)
  • Guus der Kinderen

    Guus der Kinderen 009019b7edc72a577b82f9f2b051a01ae3fcde89

    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).

    • xmppserver/src/main/java/org/jivesoftware/openfire/ldap/LdapVCardProvider.java (version 009019b7edc72a577b82f9f2b051a01ae3fcde89)
  • Guus der Kinderen

    Guus der Kinderen 1a7c4fd96ba690e6005225fb8aaddaed10044d5b

    LDAP: reduce log verbosity when requesting data for unknown user.

    • xmppserver/src/main/java/org/jivesoftware/openfire/ldap/LdapVCardProvider.java (version 1a7c4fd96ba690e6005225fb8aaddaed10044d5b)
  • Guus der Kinderen

    Guus der Kinderen 07ecd07ad87a2b09863cabdb6d02c05da261317c

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/auth/JDBCAuthProvider.java (version 07ecd07ad87a2b09863cabdb6d02c05da261317c)
  • Guus der Kinderen

    Guus der Kinderen 2759a5c642c799251cf6ce7115dae5aaefddb93f

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQvCardHandler.java (version 2759a5c642c799251cf6ce7115dae5aaefddb93f)
  • Guus der Kinderen

    Guus der Kinderen 7c52305534bd493ce1a3054c7ad32153976b7716

    Minor VCard improvements

    • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQvCardHandler.java (version 7c52305534bd493ce1a3054c7ad32153976b7716)
  • Guus der Kinderen

    Guus der Kinderen 00c88addd5fa8541b0318258bee4693d15d17142

    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.

    • i18n/src/main/resources/openfire_i18n.properties (version 00c88addd5fa8541b0318258bee4693d15d17142)
    • i18n/src/main/resources/openfire_i18n_nl.properties (version 00c88addd5fa8541b0318258bee4693d15d17142)
    • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQvCardHandler.java (version 00c88addd5fa8541b0318258bee4693d15d17142)
  • Guus der Kinderen

    Guus der Kinderen b3f6919dd04afed190182e0807f89b68332f3983

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/entitycaps/EntityCapabilitiesManager.java (version b3f6919dd04afed190182e0807f89b68332f3983)
  • Guus der Kinderen

    Guus der Kinderen 303369d0eb078bc4c5bd0e6e44bed0917ad3df80

    OF-2836: CapsManager should use provided algorithm
    Use the provided algorithm for entity capability calculation, rather than assuming that it's `SHA-1`.

    • xmppserver/src/main/java/org/jivesoftware/openfire/entitycaps/EntityCapabilitiesManager.java (version 303369d0eb078bc4c5bd0e6e44bed0917ad3df80)
  • Guus der Kinderen

    Guus der Kinderen fcca17d42db26927113e4944b9658e5303bc15be

    Apply IDE suggestions
    Minor, non-functional changes suggested by the IDE (spelling, non-needed code, etc).

    • xmppserver/src/main/java/org/jivesoftware/openfire/entitycaps/EntityCapabilitiesManager.java (version fcca17d42db26927113e4944b9658e5303bc15be)
  • Guus der Kinderen

    Guus der Kinderen 76b8b7f62f32bfbef8d7526b49324762678565c3

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/disco/IQDiscoInfoHandler.java (version 76b8b7f62f32bfbef8d7526b49324762678565c3)
    • xmppserver/src/main/java/org/jivesoftware/openfire/disco/IQDiscoItemsHandler.java (version 76b8b7f62f32bfbef8d7526b49324762678565c3)
    • xmppserver/src/main/java/org/jivesoftware/openfire/handler/IQHandler.java (version 76b8b7f62f32bfbef8d7526b49324762678565c3)
  • Guus der Kinderen

    Guus der Kinderen 417657b7e296a458bc140a760956a351c74c7c61

    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).

    • xmppserver/src/main/java/org/jivesoftware/openfire/SessionManager.java (version 417657b7e296a458bc140a760956a351c74c7c61)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalSession.java (version 417657b7e296a458bc140a760956a351c74c7c61)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/RemoteIncomingServerSession.java (version 417657b7e296a458bc140a760956a351c74c7c61)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/RemoteSession.java (version 417657b7e296a458bc140a760956a351c74c7c61)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/Session.java (version 417657b7e296a458bc140a760956a351c74c7c61)
  • Guus der Kinderen

    Guus der Kinderen 4e0e4829dd0e299092664139bb23db6bf654240d

    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).

    • xmppserver/src/main/java/org/jivesoftware/openfire/RoutingTable.java (version 4e0e4829dd0e299092664139bb23db6bf654240d)
    • xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalClientSession.java (version 4e0e4829dd0e299092664139bb23db6bf654240d)
    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 4e0e4829dd0e299092664139bb23db6bf654240d)
  • Guus der Kinderen

    Guus der Kinderen 30ab578e48227a8b2b7de165f690de980a8f528b

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 30ab578e48227a8b2b7de165f690de980a8f528b)
  • Guus der Kinderen

    Guus der Kinderen 67108eddd2346099eab7cd4081286548c8bf3d70

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 67108eddd2346099eab7cd4081286548c8bf3d70)
  • Guus der Kinderen

    Guus der Kinderen 3c7a0c684939ca5738868689360d22cb3583904a

    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.

    • xmppserver/src/main/java/org/jivesoftware/openfire/RoutingTable.java (version 3c7a0c684939ca5738868689360d22cb3583904a)
    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 3c7a0c684939ca5738868689360d22cb3583904a)
  • Guus der Kinderen

    Guus der Kinderen 4570e79b926538fb137f8b1a00dff10b10f57b37

    Add code comment explaining re-entrant lock usage

    • xmppserver/src/main/java/org/jivesoftware/openfire/spi/RoutingTableImpl.java (version 4570e79b926538fb137f8b1a00dff10b10f57b37)
  • Guus der Kinderen

    Guus der Kinderen 1e109775535b8c8c97d51843501cbec2ee8e95f9

    Fixed a typo

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