| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes that selecting libevent when unavaibalbe would fall back to select
instead of epoll, even if that's available.
This way, we only have to update it in once place when choosing a new
default.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In a case like this the timer would not be readded:
addtimer(1, function(t, id)
stop(id)
return 1
end);
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MattJ on 09:34:24
> Zash: I think as a first step, offline messages should not be sent to
> clients that request MAM
https://chat.modernxmpp.org/log/modernxmpp/2021-08-31#2021-08-31-8518a542bd283686
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Otherwise a message archived by a remote server would be incorrectly
silently discarded. This should be safe from spoofing thanks to
strip_stanza_id earlier in the event chain.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Along with the previous commit, allows building the XML thing yourself,
should you wish to send it yourself or use it in a different context than
an iq reply.
API change: The 'reply' is removed from the event.
|
| | | |
| | |
| | |
| | |
| | | |
This way you get the _prepared_ services and don't have to do that mapping
yourself.
|
| | | |
| | |
| | |
| | | |
Please don't be accidentally quadratic.
|
| | | | |
|
| |\| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Likely affected rescheduling but have no reports of this.
After readding a timer, it would have been issued a new id. Rescheduling
would use the previous id, thus not working.
|
| |\| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
POSIX is quite explicit regarding the precedence of AND-OR lists [0]:
> The operators "&&" and "||" shall have equal precedence and shall be
> evaluated with left associativity. For example, both of the following
> commands write solely `bar` to standard output:
> false && echo foo || echo bar
> true || echo foo && echo bar
Given that, `prosody.version` target behaves as
((((((test -f prosody.release && cp ...) ||
test -f ...) &&
sed ...) ||
test -f ...) &&
hexdump ...) ||
echo unknown > $@)
In the case of release tarballs, `prosody.release` does exist, so the
first AND pair is executed. Given that it's successful, then the first
`test -f` in the OR pair is ignored, and instead the `sed` in the AND
pair is executed. `sed` success, as `.hg_archival.txt` exists, making
the second `test -f` in the OR pair ignored, and `hexdump` in the AND
pair is executed. Now, given that `.hg` doesn't exist, it fails, so the
last `echo` is run, overwriting `prosody.version` with `unknown`.
This can be worked around placing `()` around the AND pairs. Decided to use
conditionals instead, as I think they better communicate the intention
of the block.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_03
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, if surrounding code was not configuring the TLS context
used default in net.http, it would not validate certificates at all.
This is not a security issue with prosody, because prosody updates the
context with `verify = "peer"` as well as paths to CA certificates in
util.startup.init_http_client.
Nevertheless... Let's not leave this pitfall out there in the open.
|
| |\| | |
|
| | |/
| |
| |
| | |
to offer
|
| | | |
|
| | |
| |
| |
| |
| | |
Since version 0.4 of XEP-0313, the <fin/> element is sent with the IQ
result and no longer has a queryid attribute.
|
| | |
| |
| |
| |
| |
| | |
Only relevant because a "dirty" connection (with incoming data in
LuaSocket's buffer) does not count as "readable" according to epoll, so
special care needs to be taken to keep on processing it.
|
| | |
| |
| |
| |
| | |
Could allow e.g. a XEP-0198 implementation to efficiently send ack
requests at optimal times without using timers or nextTick.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allows sneaking in things in the write buffer just before it's sent to
the network stack. For example ack requests, compression flushes or
other things that make sense to send after stanzas or other things.
This ensures any additional trailing data sent is included in the same
write, and possibly the same TCP packet. Other methods used such as
timers or nextTick might not have the same effect as it depends on
scheduling.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Signals that any pending outgoing stanzas that were in the write buffer
have at least been sent off to the Kernel and maybe even sent out over
the network.
See 7a703af90c9c for mod_c2s commit
|
| | |
| |
| |
| |
| |
| | |
Storage drivers may issue their own IDs tho none of the included ones do
this atm, but the 3rd party module mod_storage_xmlarchive has its
special format.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Should prevent further opportunistic write attempts after the kernel
buffers are full and stops accepting writes.
When combined with `keep_buffers = false` it should stop it from
repeatedly recreating the buffer table and concatenating it back into a
string when there's a lot to write.
|
| | |
| |
| |
| |
| | |
Not currently used for anything, but allowed and could be used in the
future and might be used by other servers.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Makes it so that global values set in the environment are kept longer
than within one line, and thus can be used until the session ends. They
still don't pollute the global environment, which is an error anyway.
Thanks phryk for noticing.
|
| | |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| |\| |
|
