Looks like clients using strophejs aren't able to authenticate when we
add data required by that spec to scram packets, so at least give a way
to disable this until clients will be fixed.
This makes `user_check` hook work better with authentication methods
that don't have a way to determine if user exists (like is the case for
jwt and cert based authentication), and as result will improve mod_offline
and mod_mam handling of offline messages to those users. This reuses
information stored by `mod_last` for this purpose.
Should fix issue #3377.
This option is read during ejabberd start or config reload.
It installs the listed modules which aren't yet installed,
as long as allow_contrib_modules is not disabled.
Edit ejabberd.yml and configure the desired ejabberd-contrib modules,
add them in the install_contrib_modules option,
finally start ejabberd (or reload config).
* Add log_burst_limit_* options
On our ejabberd deployment we were sometimes seeing more than 500
msgs/sec of legitimate traffic, however this was getting silently
dropped. Provide config options to enable this limit to be configured
from the config file.
* Pass new logging vars in via ejabberdctl
This change requires Erlang/OTP-21.0 or higher.
The commit also deprecates the following options:
- log_rotate_date
- log_rate_limit
Furthermore, these options have no effect. The logger now fully
relies on log_rotate_size, that cannot be 0 anymore.
The loglevel option now accepts levels in literal formats.
Those are: none, emergency, alert, critical, error, warning, notice, info, debug.
Old integer values (0-5) are still supported and automatically converted
into literal format.
Reasons:
- Riak DB development is almost halted after Basho
- riak-erlang-client is abandoned and doesn't work
correctly with OTP22
- Riak is slow in comparison to other databases
- Missing key ordering makes it impossible to implement range
queries efficiently (e.g. MAM queries)
This option was introduced to fulfill requirement of RFC3920 10.3,
but in practice it was very inconvenient and many admins were
forced to change its value to 's2s' (i.e. to behaviour that
violates the RFC). Also, it seems like in RFC6120 this requirement
no longer presents.
Those admins who used this option to block s2s with their subdomains
can use 's2s_access' option for the same purpose.
Option 'captcha_host' is now deprecated in favor of 'captcha_url'.
However, it's not replaced automatically at startup, i.e. both options
are supported with 'captcha_url' being the preferred one.
Paweł Chmielowski