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.
