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.
If stream management is enabled, let mod_ping trigger XEP-0198
<r/>equests rather than sending XEP-0199 pings. This avoids the
overhead of the ping IQ stanzas, which, if stream management is enabled,
are accompanied by XEP-0198 elements anyway.
Thanks to MoyaApp (<https://moya.app>) for sponsoring this work.
When configured like:
listen:
-
request_handlers:
/api: mod_http_api
/apizero/v0: mod_http_api
What API version will be used depending on the URL:
- api/commandname use the latest available version
- api/commandname/v0 use version 0
- apizero/v0/commandname use version 0
- apizero/v0/commandname/v2 use version 2
Remove the correct field from the c2s state when the client explicitly
disables push notifications. This fixes a regression introduced by
commit c148ab4430.
This timeout also covers in-band registration, and if user don't fill
registration form in that time leads to disconnect and aborting
registration. This will allow for more time to finish that.
Looks like originally both soft and hard worked the same way, so lets make
them do that, and we also need to add {verify, verify_none} for false case
otherwise it fails on R26.
Looks like R26 generates error when this option is used for client
connection, let's just use verify_peer/verify_none for
ldap_tls_verify hard/soft options.
This should fix issue #4110.
Owner is already permitted to delete those items, so it could do that by
deleting old item, and publishing it again, so i don't see reason to not
allow that overwrite.
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.
Registering a nick in the MUC service or in a room is mutually exclusive:
- A nick that is registered in the service cannot be registered in any
room, not even the original owner can register it.
- Similarly, a nick registered in any room cannot be registered in the
service.
We do something similar for vcard queries, this allows target server
to respond to those queries by target server, which is what we want to
do in both of those cases.
When formatting the results of a command:
- If the top of the result is a list, split elements with newline as usual
- If it's a list in one of the resulting lines, split elements with ;
If the new 'notify_on' option is set to 'messages', notifications are
only triggered by actual chat messages with a body (or encrypted
payload). The default behavior remains to generate a notification on
any kind of stanzas.
Thanks to EISST International Ltd for sponsoring this work.
Recently we added new places where we call muc_filter_message to add
occupandid info to messages, but this also made them be stored in archive
as mod_mam uses that hook for getting sent messages - in case of those
messages we shouldn't be doing this.
This should fix issue #4083
When changing the room subject, store the original author JID,
so later it can be provided in the hook and mod_room_occupantid
can use it to calculate and provide the occupant id
This is noticeable when a new occupant joins an existing room,
and receives the room subject.
Don't (ab)use the gen_server timeout mechanism for pinging the systemd
watchdog. Under certain conditions (e.g., the process receiving sys
messages), the gen_server timeout might not be triggered as expected.
Fixes#4054, fixes#4058,
Check whether mod_push_keepalive is loaded for a given host before
querying the module configuration for that host. This avoids a hook
crash in the case where the module is enabled for some but not all
hosts.
Delay the 'wake_on_start' notifications until ejabberd is fully
initialized. This makes sure no s2s connections are initiated before
certificates are loaded.
Many thanks to Friedrich Altheide for reporting the issue.
Setting scram password, then disabling scram and setting plain password
again, will make us think we are still using scramed password and crash
when trying to process it as such. This makes sure that when set plain
password we don't leave parts from old scram password.