XEP-0388 says: "SASL2 MUST only be used by Clients or offered by Servers
after TLS negotiation". Therefore, we reject SASL2 negotiations over
unencrypted transports by default. However, TLS might be terminated
outside of ejabberd. Add the 'allow_unencrypted_sasl2' option to
support this use case.
Ignore node plugin defaults if the plugin handling the request isn't
enabled, rather than ignoring 'default_node_config' options and
applying plugin defaults in that case.
Use any option specified via 'default_node_config' by default, and take
the remaining defaults from the node plugin handling the request. This
is the documented behavior.
Before this change, the code applied the plugin defaults only if no
'default_node_config' existed at all. And even this logic didn't work
as intended, since 'default_node_config' yielded an empty list in case
it wasn't configured, which resulted in plugin defaults never being
applied.
Don't merge 'default_node_config' settings with the default options of
the first configured node plugin. Otherwise, the latter might later
override those of the plugin that should handle a node creation request.
For example, the following configuration would lead to the 'flat'
options being used by default for 'pep' nodes as well:
mod_pubsub:
plugins:
- flat
- pep
So far, ejabberd_update:update/0 returned the return value of
release_handler_1:eval_script/1. That function returns the list of
updated but unpurged modules, i.e., modules where one or more processes
are still running an old version of the code. Since commit
5a34020d23, the ejabberd 'update' command
assumes that value to be the list of updated modules instead. As
that seems more useful, modify ejabberd_update:update/0 accordingly.
This fixes the 'update' command output.
Since commit 514c25caef, whenever a PEP
item was published, a notification was blindly sent back to the owner.
However, this should only be done subject to +notify filtering, as per
XEP-0163:
| the PEP service shall send notifications to all of the account owner's
| available resources (subject to notification filtering).
The motivation for the mentioned commit was that +notify subscriptions
initially didn't work for PEP node owners (#2108). However, that issue
was fixed by commit 5968bc9318 (#2112).
As a result, the owner's client was actually notified twice if the
client was subscribed to the node (e.g., via +notify).
Therefore, just omit the additional, blind notification.
Thanks to W. Martin Borgert and Daniel Gultsch for reporting the issue.
This removes handling of pre-rfc7395 encapsulation of xmpp in websocket
(where data send in websocket was using just raw data as send in regular
socket). This didn't work correctly for last 5 years, and as we didn't
see complains about this, we can assume it's not used anymore.
This also makes batch of schema updates to single table use transaction,
which should help in not leaving table in inconsistent state if some update
steps fails (unless you use mysql where you can't rollback changes to
table schemas).
