Note that support for older specification is completely dropped,
i.e. no backward compatibility is provided since the XEPs are
still very experimental and being changed drastically
This change should apply usual logic for message wrapped in mucsub except
check for groupchat message, so messages without bodies for example
should be rejected
As mod_offline currently doesn't preserve metadata, add an explicit
check for messages retrieved from offline storage to avoid stripping
their stanza IDs.
Thanks to Zuglufttier for spotting this.
After some discussion with the community it was decided to
clean the configuration file from excessive comments and
explicitly configured default values. Also, mod_mam and
mod_http_upload have been added.
The rationale for this is to have a clean and not bloated
configuration file which doesn't scare away newcomers and
which has all features from the Compliance Suite 2018 (XEP-0387)
enabled by default.
For further configuration an admin is encouraged to read the
documentation at https://docs.ejabberd.im/admin/configuration
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
Since we got rid of all bottle-neck processes and we have
a connection pool for every database, the option is no longer
needed and in fact is detrimental: in practice what you get
is just a bunch of overloaded processes in the IQ handlers pool
no matter how much you increase the `iqdisc` value.
Given that there are close to zero operators understanding
the meaning of the option and, hence, not using it all,
it's not simply deprecated but completely removed.
The commit also deprecates the following functions:
- gen_iq_handler:add_iq_handler/6
- gen_iq_handler:handle/5
- gen_iq_handler:iqdisc/1
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
The callback is supposed to provide known options and their default
values, as long as the documentation. Passing default values into
get_mod functions is now deprecated: all defaults should be provided
by the Mod:mod_options/1 callback.
Let mod_mam use the 'sm_receive_packet' hook to generate stanza IDs for
incoming messages, but not to actually store them. The latter would
require additional changes to make sure modules such as mod_privacy and
mod_block_strangers continue to affect MAM.
If mod_offline is disabled but a message is archived by mod_mam, no
error bounce should be generated. This functionality got lost when
mod_mam stopped using the 'offline_message_hook'.
Now that mod_mam no longer uses the 'offline_message_hook', avoid
duplicating notifications for messages written to both MAM and offline
storage in another way.
XEP-0359 v0.5.0 says: "Stanza ID generating entities, which encounter a
<stanza-id/> element where the 'by' attribute matches the 'by' attribute
they would otherwise set, MUST delete that element even if they are not
adding their own stanza ID."
Let mod_mam store incoming messages from a new hook in ejabberd_sm.
This makes sure all messages are tagged with a stanza ID, including
those that are forked to multiple resources in ejabberd_sm.
Closes#1344.
Refuse filtering anon MUC MAM queries by JID even if it's the client's
own JID. Clients probably won't perform such queries in practice, so
the additional complexity is unnecessary.
The changes are very similar to those from previous commit:
* Now there is no need to pass validating function in
gen_mod:get_opt() and gen_mod:get_module_opt() functions,
because the modules' configuration keeps already validated values.
* New functions gen_mod:get_opt/2 and gen_mod:get_module_opt/3 are
introduced.
* Functions gen_mod:get_opt/4 and get_module_opt/5 are deprecated.
If the functions are still called, the "function" argument is
simply ignored.
* Validating callback Mod:listen_opt_type/1 is introduced to validate
listening options at startup.
It's now possible to use files as internal packet queues.
The following options are introduced:
* queue_type: the option can be set to `ram` (default) or `file`.
The option can be set per virtual host.
* queue_dir: path to the directory where queues will be allocated.
The default is 'queue' directory inside Mnesia directory.
This is a global option and cannot be set per virtual host.
Now 'From' and 'To' arguments must be omitted in functions
and structures related to routing.
The commit deprecates the following functions:
ejabberd_router:route/3 in favor of ejabberd_router:route/1
ejabberd_router:route_error/4 in favor of ejabberd_router:route_error/2
ejabberd_local:route_iq/4 in favor of ejabberd_local:route_iq/2
ejabberd_local:route_iq/5 in favor of ejabberd_local:route_iq/3
The format of {route, From, To, Packet} is changed in favor of {route, Packet}
When multiple resources have the same (highest) priority, ejabberd_sm
dispatches messages addressed to the bare JID (or to an unavailable
resource) to each of these resources. Such messages are now marked with
an 'sm_copy' flag for all but one of the resources. This makes it
easier for other modules to identify those duplicates.
Resolves#1356.
Use the user (or room) JID instead of the server JID for the 'by'
attribute of <stanza-id/> and <archived/> tags. That's what the
examples in XEP-0313 v0.2 and XEP-0359 v0.3.0 suggest.
XEP-0313 says: "a server SHOULD include in a user archive all of the
messages a user sends or receives of type 'normal' or 'chat' that
contain a <body> element."
The "assume_mam_usage" option now takes a boolean value. Setting it to
"true" has the same effect as "if_enabled" had before. The "on_request"
behavior is no longer offered, as it made the option (and its
documentation) overly complex.
Limit the number of messages returned for a given MAM request even if
the client didn't specify an RSM set (not just if the client specified
an RSM set without a limit).
This is still not done for MAM v0.2 requests though, as that version of
the XEP doesn't require clients to support RSM.
