If stream management is enabled, don't exit the c2s process when
ejabberd_socket:send/2 fails, but close the socket instead. This gives
the client a chance to resume the session.
Thanks go to Matthias Rieber for reporting the issue, providing detailed
logs, and testing the fix.
Only the child elements of <iq/> stanzas are qualified by the namespaces
in question, not the <iq/> stanzas themselves.
This change just clarifies the code. It doesn't alter the behaviour, as
those <iq/> stanzas are handed over to jlib:iq_to_xml/1, and that
function ignores the 'xmlns' attribute anyway.
Regarding "extauth_cache", the guide says: "The integer 0 (zero) enables
caching for statistics, but doesn't use that cached information to
authenticate users." Make sure the cached password isn't used even if
the user is currently logged in with another resource.
Only stanzas are subject to stream management, so when XEP-0198 support
is enabled, we must distinguish them from non-stanza elements. This
commit adds a send_packet/2 function that can be used in place of
send_stanza/2 or send_element/2 whenever a packet is delivered that
might or might not be a stanza.
If the client says that it handled more stanzas than we sent (due to a
bug in the client's or in our code), increase our outgoing stanza count
accordingly. There's no point in sticking to the old value even if it
was correct, as the client surely won't fix its count during the current
session.
Do not log a warning (but only a debug message) if the client sends an
invalid </a> packet. Some clients do that occasionally, and there's
nothing server admininistrators could do about that.
There are corner cases where certain clients acknowledge more stanzas
than they received. Nothing really bad will happen in those cases, and
server administrators can't do anything about such issues anyway.
Due to timing issues, ejabberd_c2s might receive stream elements from
the client while the session is waiting for stream resumption. Those
elements are now accepted.
Log an informational message when a session goes into the pending state
(waiting for resumption) after the connection was lost. Administrators
may well be interested in this state change when looking into issues.
Don't print the following message if an ejabberd command expects binary
string arguments: "This command cannot be executed using ejabberdctl.
Try ejabberd_xmlrpc."
Handle "s2s_use_starttls: required_trusted" the same way for outgoing
s2s connections as for incoming connections. That is, check the remote
server's certificate (including the host name) and abort the connection
if verification fails.
Don't try to look up and close outgoing connections to a given server
when aborting incoming connections from that server due to certificate
verification errors. The ejabberd_s2s:find_connection/2 call actually
created one or more *new* connections if less than 'max_s2s_connections'
connections were found. Then, no more than one of those possibly new
connections were stopped by the ejabberd_s2s_out:stop_connection/1 call.
It's not really necessary to bother with outgoing connections at all,
here.
Prior to this commit, ejabberd handled certificate authentication for
incoming s2s connections like this:
1. Verify the certificate without checking the host name. On failure,
behave according to 's2s_use_starttls'. On success:
2. Offer SASL EXTERNAL.
3. If the remote server chooses SASL EXTERNAL, compare the authorization
identity against the certificate host name(s). On failure, abort the
connection unconditionally.
ejabberd now does this instead:
1. Verify the certificate and compare the certificate host name(s)
against the 'from' attribute of the stream header. On failure,
behave according to 's2s_use_starttls'. On success:
2. Offer SASL EXTERNAL.
3. If the remote server chooses SASL EXTERNAL, ignore the authorization
identity (if any) and consider the peer authenticated.
The old behavior was suggested by previous versions of XEP-0178, the new
behavior is suggested by the current version 1.1.
Don't log a "configuration problem" message if "extauth_cache: false" is
explicitly specified, as that's a valid configuration setting as per the
documentation.
