| 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
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Gives a better idea of what's taking time.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Modules using ids for logging should not need the now pretty large
medium one.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Using a dedicated service should give identical behavior, except for a
possible timing difference in the user existence lookup.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Ensures configuration is refreshed, releases some memory.
|
| |
| |
| |
| | |
to offer
|
| | |
|
| |
| |
| |
| |
| | |
The vision: All the queueing and counting and session replacement logic
in core, with mod_smacks only hooking this up to the XEP-0198 protocol.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
It could have been resumed without going into hibernation first, i.e.
when the client notices the disconnect before the server, or if it
switches networks etc.
|
| |
| |
| |
| |
| | |
Errors sent from handle_unacked_stanzas() should usually not be sent to
the session itself, but if one is, it should not be queued.
|
| |
| |
| |
| |
| | |
Fixes that an extra watchdog was set, leaking the previous one, which
went on to do behave as if the session times out.
|
| |
| |
| |
| |
| |
| |
| |
| | |
With mod_smacks, a session can outlive the connection, so whether the
event is fired should not hinge on whether the session is connected or
not.
Helps mod_smacks remove some state.
|
| |
| |
| |
| |
| |
| | |
Still having the connection on the session may cause unintentional
behavior, such as the session being treated as if connected, even tho
the connection has been closed.
|
| | |
|
| |
| |
| |
| | |
Was this the last place using the delay? Nice!
|
| |
| |
| |
| |
| | |
Otherwise it can get stuck waiting indefinitely for an ack that made it
notice the connection was stale.
|
| |
| |
| |
| | |
Non-existent did not seem entirely accurate for this case
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Less to type if per chance the next commit also wants to access
sessions.
|
| |
| |
| |
| |
| |
| | |
To ensure that if a session is replaced after it has gone into
hibernation, it does not come back and cause trouble for the new session
(see previous commit).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The resumption_token is removed when the session is closed via the
pre-session-close event, signaling that it cannot be resumed, and
therefore no hibernation timeout logic should be invoked.
Fixes that if a session somehow is replaced by a new one using the same
resource (which is the common behavior), the old session would still be
around until it times out at which point it sends `<presence
type="unavailable"/>` which would look as if it came from the new
session, ie appearing offline to everyone including MUCs.
|