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.
As the session manager handles messages sent to unavailable resources
just like messages sent to bare JIDs, mod_carboncopy must do that, too.
That is, forward them only to those carbon-copy-enabled resources that
don't have a top priority, in order to avoid duplicates.
On connection timeout, drop any messages that were forwarded by some
encapsulating protocol, such as XEP-0280 carbon copies or XEP-0313
archive messages. Bouncing or resending them could easily lead to
unexpected results.
Implement the optional session resumption feature described in XEP-0198.
A client that supports this feature may now resume the previous session
(within a configurable number of seconds) if the connection was lost.
During resumption, ejabberd will retransmit any stanzas that hadn't been
acknowledged by the client.
Implement partial support for XEP-0198: Stream Management. After
successful negotiation of this feature, the server requests an ACK for
each stanza transmitted to the client and responds to ACK requests
issued by the client. On session termination, the server re-routes any
unacknowledged stanzas. The length of the pending queue can be limited
by setting the "max_ack_queue" option to some integer value (default:
500). XEP-0198 support can be disabled entirely by setting the
"stream_management" option to false (default: true).
So far, stream management is implemented only for c2s connections, and
the optional stream resumption feature also described in XEP-0198 is not
(yet) supported.
This addition was originally based on a patch provided by Magnus Henoch
and updated by Grzegorz Grasza. Their code implements an early draft of
XEP-0198 for some previous version of ejabberd. It has since been
rewritten almost entirely.
By calling:
ejd2odbc:export_pubsub("localhost","/tmp/aa.txt").
it will generate SQL files like these:
/tmp/pubsub_item.txt
/tmp/pubsub_node.txt
/tmp/pubsub_state.txt
Conflicts:
src/ejabberd_admin.erl
src/ejd2odbc.erl
