RFC 6120 states that
> If the initiating entity does not wish to act on behalf of another
> entity, it MUST NOT provide an authorization identity.
Thus it seems weird to require it here. We can instead expect an
username from the token data passed back from the profile.
This follows the practice of util.sasl.external where the profile
callback returns the selected username, making the authentication module
responsible for extracting the username from the token.
E.g. module:info("http") with many http modules loaded would show a lot
of duplication, as each module would be listed for each host, even if
not actually enabled on that host.
Some of the OAuth stuff highlights a small need to retrieve a list of
roles somehow. Handy if you ever need a role selector in adhoc or
something.
Unless there's some O(n) thing we were avoiding?
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.
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.
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.
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.
Since resumption is not supported on s2s currently, there is no point in
allocating resumption tokens. The code that removes entries from
session_registry is only invoked for c2s sessions, thus enabling
resumable smacks on s2s adds an entry that never goes away.
