| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| |
| | |
This is designed for use by other modules that want to accept tokens issued
by mod_tokenauth, without duplicating all the necessary logic.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows tokens to be tied to specific purposes/protocols. For example, we
shouldn't (without specific consideration) allow an OAuth token to be dropped
into a slot expecting a FAST token.
While FAST doesn't currently use mod_tokenauth, it and others may do in the
future. It's better to be explicit about what kind of token code is issuing or
expecting.
|
| |
| |
| |
| | |
The token layer supports tokens that are tied to a given resource.
|
| |
| |
| |
| | |
Enables UI in clients supporting XEP-0050
|
| |
| |
| |
| | |
First proper UI to enable/disable, allowing it to be tested.
|
| |
| |
| |
| |
| |
| |
| |
| | |
We decided that at the first stage, accounts that are disabled should
simply be prevented from authenticating, thus they should also be
prevented from having connected sessions. Since this is aimed to be a
moderation action for cases of abuse, they shouldn't be allowed to
continue being connected.
|
| | |
|
| |
| |
| |
| | |
Uses 'disabled' property already introduced in aed38948791f
|
| |
| |
| |
| | |
But how and where?
|
| |
| |
| |
| |
| |
| | |
Moving this out will make space for a dynamic check whether a particular
user is disabled or not, which is one possible response to abuse of
account privileges.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This event was added in a7c183bb4e64 and is required to make mod_smacks know
that a session was intentionally closed and shouldn't be hibernated (see
fcea4d9e7502).
Because this was missing from mod_websocket's session.close(), mod_smacks
would always attempt to hibernate websocket sessions even if they closed
cleanly.
That mod_websocket has its own copy of session.close() is something to fix
another day (probably not in the stable branch). So for now this commit makes
the minimal change to get things working again.
Thanks to Damian and the Jitsi team for reporting.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
When mod_admin_socket is loaded without mod_admin_shell, attempt to use
`prosodyctl shell` will appear to freeze after any input, since no
response is returned.
|
| |
| |
| |
| |
| | |
Expected this to be translated to 'core', but it logs an error instead.
See previous commit.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Allows retrieving this in e.g. a health reporting module
Thanks pfak
|
| |
| |
| |
| | |
Maybe one day we'll get consistent filtering semantics everywhere.
|
| |
| |
| |
| | |
Suggested by MattJ, our resident UI expert :)
|
| |
| |
| |
| |
| | |
The length of the title "Affiliation" made them both close enough that
it looked off.
|
| |
| |
| |
| | |
Tables are awesome!
|
| |
| |
| |
| | |
Justification: See diffstat
|
| |
| |
| |
| |
| | |
Easier than going trough muc:room():each_affiliation() since you have to
do fiddly things to reach the print() function.
|
| |
| |
| |
| |
| | |
Easier than going trough muc:room():each_occupant() since you have to do
fiddly things to reach the print() function.
|
| |
| |
| |
| | |
See also 781772c8b6d9
|
|\| |
|
| |
| |
| |
| |
| | |
Not sure why this was missing from MUC MAM, it already had some of the
code for dealing with it.
|
| |
| |
| |
| | |
Oversight in cabb022f31c0
|
| |
| |
| |
| |
| | |
Should have no functional difference, but makes it easier keeping
mod_mam and mod_muc_mam in sync.
|
| | |
|
| |
| |
| |
| | |
Introduced in 6966026262f4
|
|\| |
|
| |
| |
| |
| |
| | |
Will hopefully save future confusion about sessions being destroyed when
they are in fact not.
|
| | |
|
|\| |
|
| |
| |
| |
| | |
To mirror behavior of prosodyctl invocation
|
|\| |
|
| |
| |
| |
| | |
Patch by Peter Kieser
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes `prosodyctl adduser` etc.
Prior to d580e6a57cbb the line did nothing.
Sometimes storage in the prosodyctl context does cause weirdness, as it
is not in a host context, but rather a variant of global.
|
| |
| |
| |
| |
| |
| |
| | |
Secure delegation or "Mini-DANE"
As with the existing DANE support, only usable in one direction, client
certificate authentication will fail if this is relied on.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Having mod_s2s know about the bidi namespace is perhaps a bit awkward
but putting this in mod_s2s_bidi would be more awkward as it has nothing
to do with limits. Some indirection event could be added in the future.
|
| | |
|
| |
| |
| |
| | |
As introduced in XEP-xxxx: Stream Limits Advertisement
|
| |
| |
| |
| | |
Thanks MattJ
|
| |
| |
| |
| |
| |
| |
| |
| | |
Just dropping them isn't great but hopefully something more sensible can
be done in the future.
Will need work to ensure that this signal is handled correctly in
sending modules etc.
|
| |
| |
| |
| | |
For future use, i.e. canceling sending of stanzas that exceed the limit
|