During XEP-0198 resumption, the ejabberd_c2s process that handles the
new connection reopens the ejabberd_sm session of the old one. Since
commit b4770815c0, the new process adds
the new session table entry before the old process removes the old one.
While adding the new one, ejabberd_sm checks for old sessions to
replace. This check assumes old SIDs compare lower than new ones. This
assumption didn't necessarily hold for the session resumption case,
where the old SID's timestamp was copied over to the new SID and only
the PID was updated. Therefore, the new process was killed if the new
PID happened to be smaller than the old one.
Fix this by having mod_stream_mgmt use its own SM-ID rather than copying
over the old SID's timestamp to the new SID.
Thanks to Thilo Molitor and Friedrich Altheide for reporting the issue,
and to Thomas Leister for his help with debugging it.
Previously we only send that presence to direct presence recipients if
client also sent general self presence (without to attribute).
This should help with issue #3245
The default value for the 'max_fsm_queue' option was set to 10000 in
commit 79685da90b, and that value is still
documented to be the default. It was (probably unintentionally) changed
to 5000 in commit 03de853e4f.
It makes sense to keep it larger than the value of mod_stream_mgmt's
'max_ack_queue' option.
It looks like old version of Smack don't accept request that are have
from sent to sender jid, but are only working when jid is set to server
address. This is also how it looks in old xmpp rfc examples.
Calling sync version of xmpp_stream_in/out:stop could lead to messages
never being processed by c2s process if they were queued in p1_server.
This could be reproduced by when having messages in offline storage,
starting sessions, enabling stream_mgmt, sending initial presence, and then immediately
</stream:stream>, messages that mod_offline would send process would not
be bounced back by stream_mgmt.
There is possibilty that between c2s process unregistering itself from sm
and terminating, some other process could try to send something to c2s,
which could result in messages to triggering mam/offline hooks, and causing
them not to be stored in any way.
Now every such string MUST be encapsulated into ?T() macro.
The macro itself is defined in include/translate.hrl.
Example:
-module(foo).
-export([bar/1]).
-include("translate.hrl").
bar(Lang) ->
translate:translate(Lang, ?T("baz")).
Since we now require R19, we shouldn't need that anymore.
There are still couple places where p1_time_compat:unique_timestamp() is
used as there is no direct equivalent.
==== WARNING: MUST BE ADDED TO RELEASE NOTES =====
The commit introduces the following incompatibility:
- Option 'ca_path' is deprecated and has no effect anymore:
option 'ca_file' should be used instead if needed.
==================================================
The header consisted of too many unrelated stuff and macros misuse.
Some stuff is moved into scram.hrl and type_compat.hrl.
All macros have been replaced with the corresponding function calls.
TODO: probably type_compat.hrl is not even needed anymore since
we support only Erlang >= OTP 17.5
The options "inet", "inet6" and "backlog" are valid listen options, but are
currently logged as errors (even though they do work):
2018-02-28 16:08:44.141 [error] <0.338.0>@ejabberd_listener:validate_module_option:630 unknown listen option 'backlog' for 'ejabberd_c2s' will be likely ignored, available options are: access, shaper, certfile, ciphers, dhfile, cafile, client_cafile, protocol_options, tls, tls_compression, starttls, starttls_required, tls_verify, zlib, max_fsm_queue
This adds the necessary validators so they are correctly recognized.
The option can be used to specify a period (in seconds) for a stream
negotiation to complete. If the timer fires, the stream is considered
as failed and the underlying connection gets closed. This is a global
option (you cannot set it per domain) and the default is 30 seconds.
If set to `true`, all incoming XML packets are fully validated
against known schemas. If an error occurs, the packet will be bounced
with the corresponding error reason. The default value is `false`.
The option might be useful to protect client software from sofisticated
bugs related to XML validation as well as for client developers
who want to catch validation errors at early stage of development.
Note that the option might have slight performance impact, so use it
with care on loaded machines.
When the option is set to `true`, the module will generate
CAPTCHA challenges for incoming subscription requests. The option
also implies that option `drop` is set to `true`. Note that
the module won't generate CAPTCHA challenges for messages: they
will still be rejected if `drop` is set to `true`.
Fixes#2246
