| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
As suggested by RFC 7590
|
|
|
|
|
|
|
| |
Should no longer be used by anything since the conversion of mod_offline
to the archive API in 0.10.0, which was 4 years ago. The line clearing
the property is left for a bit longer in case someone has very old
offline messages or archived data.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Since version 0.4 of XEP-0313, the <fin/> element is sent with the IQ
result and no longer has a queryid attribute.
|
|
|
|
|
| |
Could allow e.g. a XEP-0198 implementation to efficiently send ack
requests at optimal times without using timers or nextTick.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
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
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
| |
| |
| |
| |
| |
| |
| | |
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 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.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Couldn't use those with the host being deactivated.
Problem: This kicks in on reload, which isn't needed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Increases log level for stream conditions that could indicate a problem
on our end, especially programming errors like invalid XML, or the
remote server saying that our certificate is invalid, since these should
be investigated.
Non-issues like closing of idle streams are lowered to debug since it's
mostly noise.
Other issues left at info are mostly about changes to the remote server,
e.g. complete or partial shutdown.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Reduces the number of left-over timers to handle after many s2s
connections were started, leaving only the ones related to incomplete
connections.
|
| |
| |
| |
| |
| |
| | |
This should probably never happen, but probably does anyways.
A debug message would show the truth of the matter.
|
| |
| |
| |
| |
| | |
Nicer to get rid of a conditional that covers such a large portion of a
pretty big function.
|
| |
| |
| |
| |
| | |
These direct accesses are probably more optimized, but weird when the
module API has methods for these things.
|
| |
| |
| |
| | |
It isn't quite an error.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Goal is to have some accountability for these privileged actions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This doesn't really make sense today. It doesn't even work with
mod_auth_internal_hashed, which should be the default. And even with a
supporting authentication module, why would we just hand out the
password? One use case may be to recover a forgotten password. While not
yet included with Prosody, there are better ways to handle forgotten
passwords, usually by resetting them to a new password.
|