This allows user creation to happen inside the running Prosody process, which
improves a number of things - such as executing event handlers for user
creation, fixing issues and race conditions with some storage drivers, etc.
The intent is to do the same for the other prosodyctl commands, but this is
the first proof of concept for the approach.
This allows us to continue sending/receiving on the session, for example if
the promise will be resolved by other data that the client is going to send.
Specifically, this allows the repl-request-input to work without a deadlock.
It does open the door to interleaved commands/results, which may not be a good
thing overall, but can be restricted separately if necessary (e.g. a flag on
the session).
This fixes an issue where e.g. remote users or even other users on the server
were unable to list MUC rooms.
We want to define a permission to list MUC rooms, but we want it to be
available to everyone by default (the traditional behaviour).
prosody:guest is the lowest role we have. I ran a quick check and it isn't
really used for anything right now that would be concerning.
It was originally designed for anonymous logins. I think it's safe to treat
remote JIDs as equivalent, since we have no trust relationship with anonymous
users either.
This allows certain session-specific code that needs to run in the async
context, but is itself triggered outside of that context (e.g. timers), to
be queued.
An example of this is the session destruction code of mod_smacks, when the
hibernation timeout is reached.
Attempt to fix a bug where connections are somehow closed twice, leading
to bad things happening elsewhere.
With LuaSec, closed connections are generally already too closed to
write anything to anyway since it does not support unidirectional
shutdown.
Attributes are strings. That definitely is a number. So we
tostring() it. This is important when the API becomes stricter,
for whatever reason that might happen.
Practically, this moves the overhead of converting to a string
to a place where it is visible.
This queue is used to buffer stanzas while waiting for an outgoing s2s
connection to be established.
Limit it to prevent excessive memory usage.
Default chosen to approximate how many average stanzas fits in the
server_epoll default max_send_buffer_size of 32 MiB
Returns a custom error instead of the default core.stanza_router
"Communication with remote domains is not enabled" from is sent back,
which does not describe what is happening here.
Closes#1106
Prevent Bad Things from happening when the buffer gets full.
This of course opens up the possibility of intentionally killing
connections by sending much stuff, which need to be mitigated with rate
limits elsewhere.
Problem: The string slice operations when a lot of data gets buffered
ends up being expensive and memory-consuming. We have util.dbuffer for
precisely this kind of thing.
I want to keep the behavior of writebuffer being upgraded from nil to a
string to full buffer since the last step involves three table
allocations, where the previous buffer method only used one. Avoiding
those allocations for simple writes like white space keep alive feels
like it would keep memory churn down.
This work was started in 2020
Previously the error messages said that it failed to "publish" to PEP, but
sometimes a sync involves removing items, which can be confusing.
The log was also the same for both legacy PEP and private XML bookmarks.
Having different log messages makes it easier to debug the cause and location
of any sync errors.
It appears that when:
1) The user has no bookmarks 2 node in PEP
2) The client publishes an empty bookmark set to a legacy bookmarks location
3) mod_bookmarks will attempt to purge items from the non-existent node and
log an error about the failure (item-not-found).
This new code will suppress an item-not-found error from the purge operation
in the empty-bookmarks case, and adds a log message for any other error (this
is helpful because the existing log message confusingly says it was an error
*publishing* to the node, which isn't always accurate).
Allows granting read only access to other sets of users using a separate
access control capability, which makes sense as some properties may be
intended to be public but read-only.
