| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This makes unlimited_jids also work for s2s connections, assuming the
remote server has been identified.
|
|
|
|
| |
Also enables reuse for s2s, which we will add next.
|
|
|
|
|
| |
So that we get single point where shared session properties can be
added. But not now. One day. Maybe. Patches welcome.
|
|
|
|
|
|
|
|
|
| |
This would also release any resources held via references from these
callbacks.
I'm not sure why we don't just re-new() the whole thing.
Related to #1382
|
|
|
|
|
| |
The assert triggers because we're not loading the stanza route, because
we are unlikely to need it during migration.
|
| |
|
|
|
|
| |
Fixes "Loading outside Prosody or Prosody not yet initialized"
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diverge from util.startup.prosodyctl() in order to skip unneeded
behavior, such as loading the *Prosody* config file, which we do not
need here, based on the `--config` flag which should point at the
migrator config file instead.
Notably removed:
* read_config() since this loads the Prosody config
* check_unwriteable() which checks logfiles specified in the Prosody config, so not relevant
* make_dummy_hosts() but the migrator sets up its own hosts during migration
|
|
|
|
|
| |
Also special thanks to timeless, for wordlessly reminding me to check
for typos.
|
|
|
|
|
|
| |
Because of the way the previous pubsub service is carried access module
reloads, it would retain the configuration options with their previous
values from when the service was first created.
|
|
|
|
|
| |
Maybe the 'service' in the outer scope should be moved down to minimize
overlap with other functions that receive the same service as argument?
|
| |
|
|
|
|
|
|
| |
XEP-0060 says that this the way to indicate that 'persistent-items' is
unsupported, but doesn't explicitly say if it being disabled in the node
configuration also counts as unsupported.
|
|
|
|
|
|
|
|
| |
This behavior came from some confusion over the meaning of
persist_items. The correct behavior is that items are only stored when
it is set to true. When set to false, the service becomes a "pure"
publish-subscribe service, where items are forgotten immediately after
broadcasting.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When set to 'false' there is no need for a persistence interface at all,
since items are not persisted after being broadcast.
Had started wondering if maybe the behavior was wrong, after reading
parts of XEP-0060 that pointed in that direction.
Some discussion of this can be found in logs of
xmpp:xsf@muc.xmpp.org?join from around 2021-07-20
Thanks to Ralph for confirming.
|
|
|
|
|
|
| |
Since nodes were always persistent according to the XEP-0060 definition.
Whether data is stored in memory or on disk was not what this setting
was meant for.
|
|
|
|
|
|
|
|
| |
This is in preparation for fixing the behavior of 'persist_items', which
was misunderstood at some point. In mod_pep it toggles between
persistent storage and in-memory storage, while the correct behavior
would be to toggle whether published items are stored at all or
forgotten after being broadcast.
|
|
|
|
|
| |
The publisher is already there on the item when the broadcaster gets it,
so it needs to do the opposite thing.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All the XEP-0060 examples have the publisher attribute set to a bare
JID, but the text does allow it to be the full JID.
Since mod_pubsub is more likely used for open nodes that anyone can
subscribe to it makes sense to not leak the full JIDs. This is also
disabled by defaults.
In mod_pep on the other hand it might make sense to have the full JID
since that data is more likely to be broadcast to contacts which are
already somewhat trusted.
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Fixes https://prosody.im/security/advisory_20210722/
Backs out 4d7b925652d9
|
| |
| |
| |
| |
| | |
Optimizes away all the processing on every message in case the
end-result is zero history.
|
| |
| |
| |
| |
| |
| | |
If this seems backwards, that' because it is but the API isn't really
designed to easily pass along details from each resolution step onto the
next.
|
| |
| |
| |
| |
| |
| | |
Removes the need to enable DANE with two separate settings.
Previously you had to also set `ssl = { dane = true }` to activate DANE
support in LuaSec and OpenSSL.
|
| |
| |
| |
| |
| | |
Previous commit adds a workaround, so this doesn't mutate global state
anymore, only per-connection 'extra' state as originally intended.
|
| |
| |
| |
| |
| |
| |
| | |
This way 'extra' is unique for each connect() instance, making it safer
to mutate it, while inheriting the global settings.
See 926d53af9a7a for some more context.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This lets various supporting editors know what indentation style should
be used for files in the repo. See https://editorconfig.org/
Coding style for Lua files is described in `doc/coding_style.md`
The 3-space indentation in `configure` comes from its LuaRocks
inheritance.
`doc/doap.xml` is normalized with `xmllint` which spits out 2-space
indentation.
|
| |
| |
| |
| |
| | |
This could happen with Dialback-only connections or others that were
missing the stream 'to' attribute.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Given an incoming <stream:stream from="example.com"> this line would
have mistakenly reported the 'from' as the local host. Neither are
technically required and may be missing, especially on connections used
only for Dialback.
Outgoing connections initiated by Prosody always have 'from_host' and
'to_host', so it is safer to check it this way.
|
| |
| |
| |
| |
| |
| |
| | |
Caused "attempt to index a string value (local 'data')", but only if
keep_buffers is set to false, which is not the default.
Introduced in 917eca7be82b
|
| |
| |
| |
| |
| | |
Read and write timeouts should usually match whether we want to read or
write.
|
| |
| |
| |
| | |
Should avoid rare but needless timer interactions
|
| |
| |
| |
| |
| | |
Instead of removing and readding the timer, keep it and adjust it
instead. Should reduce garbage production a bit.
|
| |
| |
| |
| |
| |
| |
| | |
Only real difference between the read and write timeouts is that the
former has a callback that allows the higher levels to keep the
connection alive, while hitting the later is immediately fatal. We want
the later behavior for TLS negotiation.
|
| |
| |
| |
| |
| |
| | |
Saves a function call. I forget if I measured this kind of thing but
IIRC infix concatenation is faster than a function call up to some
number of items, but let's stop at 2 here.
|
| |
| |
| |
| |
| |
| |
| | |
writebuffer is now string | { string }
Saves the allocation of a buffer table until the second write, which
could be rare, especially with opportunistic writes.
|
| |
| |
| |
| |
| | |
Reusing an already existing buffer table would reduce garbage, but
keeping it while idle is a waste.
|
| |
| |
| |
| |
| | |
So that if a write ends up writing directly to the socket, it gets the
actual return value
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A timeout value less than 0.001 gets turned into zero on the C side, so
epoll_wait() returns instantly and essentially busy-loops up to 1ms,
e.g. when a timer event ends up scheduled (0, 0.001)ms into the future.
Unsure if this has much effect in practice, but it may waste a small
amount of CPU time. How much would depend on how often this ends up
happening and how fast the CPU gets trough main loop iterations.
|
| |
| |
| |
| | |
Should Plugin really be first? What order makes the most sense?
|
| |
| |
| |
| |
| | |
This hides a whole bunch of subcommands tho, maybe those should be
explicitly listed?
|
| | |
|
| |
| |
| |
| |
| | |
Along with infrastructure for the other commands that live in external
modules.
|
| |
| |
| |
| | |
Nagle increases latency and is the bane of all networking!
|
| |
| |
| |
| |
| |
| |
| | |
Activated by setting config.tcp_keepalive to a number, in seconds.
Defaults to 2h.
Depends on LuaSocket support for this option.
|
| |
| |
| |
| |
| |
| | |
In case one wishes to enable this for all connections, not just c2s
(not Direct TLS ones, because LuaSec) and s2s. Unclear what use these
are, since they kick in after 2 hours of idle time.
|
| | |
|