| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Doing this when creating a whole new session seems reasonable because it
is already expensive and this is when it may be adding to the old
session store, while a successful resumption should be plus-minus zero.
|
| |
| |
| |
| |
| | |
For future cleanup routine when people inevitably complain about this
data being stored there forever
|
| | |
|
| |
| |
| |
| | |
Allows reuse of repetitive definitions in schemas.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Thanks Martin bringing this case to attention
|
| |
| |
| |
| |
| |
| |
| |
| | |
More security for less pain than switching to SCRAM-SHA-256
The XEP will likely be change to reference the RFC that will probably
come from draft-ietf-kitten-password-storage once it is ready, and then
we should update to follow that.
|
| | |
|
| |
| |
| |
| |
| | |
The 's2s-created' fires just after accepting the TCP connection, before
the addresses are known, so this can have some false positives.
|
| | |
|
| |
| |
| |
| |
| | |
If buckets thresholds are to be taken as "less than or equal to", then
using the less than or equal to operator seems sensible.
|
| |
| |
| |
| |
| |
| | |
The buckets thresholds are to be taken as "less than or equal to".
The condition as written in the code did only "less than", not
"less than or equal to". That's fixed now.
|
| |
| |
| |
| | |
Gives a better idea of what's taking time.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Unsure if this was overlooked before or a recent addition.
Reproduced the data from JSON file available. Would be nice to have a
tool that does that.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Presence subscriptions are normally revoked on account deletion, which
informs the contact. Sometimes this notification gets lost e.g. due to
s2s problems. The accounts JID may also be present e.g. in MUC
affiliations, chat group member lists, pubsub subscriptions or other
systems. These may grant privileges which would fall to someone who
creates the same account again, which this module is meant to prevent.
|
| | |
|
| |
| |
| |
| |
| | |
These would previously be left behind. Probably mostly harmless except
for clogging up the `debug:events()` listing in the console.
|
| |
| |
| |
| |
| |
| | |
UUID seems like insane overkill for something user-scoped and not
security-sensitive. All that is needed is to avoid conflicts among what
should be relatively long-lived sessions.
|
| |
| |
| |
| |
| | |
Conversations uses this for its randomized resources. Presumably fine
and collision resistant enough when you have a few devices at most.
|
| |
| |
| |
| |
| | |
Modules using ids for logging should not need the now pretty large
medium one.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
These provide (a) a way to deal with random assortments of certs
and (b) avoid unnecessary error messages and warnings, according
to #1669 anyway, which this fixes.
|
| |
| |
| |
| | |
instead
|
| |
| |
| |
| |
| |
| | |
By how old the commands are?
Or how disruptive the changes are?
Or just by what feels best?
|
| |
| |
| |
| |
| |
| |
| | |
Silences luacheck too
All we care about is that it is a bare JID, not a full JID with a
resource, since those are forbidden in rosters.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The other invocations use it that way, and the only listener in trunk
which uses it (in mod_presence) expects it that way.
Passing the username of the JID from the removed entry causes incorrect
unavailable presence stanzas to be sent, allegedly kicking people off
MUCs.
Fixes #1121.
|
| |
| |
| |
| | |
TLS good, SSL bad.
|
| |
| |
| |
| | |
If anyone wants that.
|
| | |
|
| |
| |
| |
| | |
ssl_preset = "modern"
|
| |
| |
| |
| |
| |
| | |
The goal is to allow module:provides("foo-bar") with a mod_foo_bar_ prefix
being stripped. It will break any existing modules that use a prefix and have
hyphens instead of underscores. No such modules are known.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This may in theory cause multiple disconnect events for the
adminstream client, if the only code using that wasn't calling
os.exit right away.
Hence, this should be a good enough partial fix for #1671. It is
not a full fix, because the shell will only notice the disconnect
after one has hit enter in the input; until then, it is stuck in
a read() call to stdin and completely oblivious to the disconnect.
|
| | |
|
| | |
|
|\| |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Data is already wiped from storage, but this ensures everything is
properly unsubscribed, possibly with notifications etc.
Clears recipient cache as well, since it is no longer relevant.
|