| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
`type(x ~= y)` is always a string, thus truthy
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is a security improvement, to ensure that sessions authenticated using a
token (note: not currently possible in stock Prosody) are invalidated just
like password-authenticated sessions are.
|
| |
|
|
|
|
|
|
|
|
|
| |
These changes to the API (hopefully the last) introduce a cleaner separation
between the user's primary (default) role, and their secondary (optional)
roles.
To keep the code sane and reduce complexity, a data migration is needed for
people using stored roles in 0.12. This can be performed with
prosodyctl mod_authz_internal migrate <host>
|
| |
|
|
|
|
| |
This also updates the module to the new role API, and improves support for
scope/role selection (currently treated as the same thing, which they almost
are).
|
| | |
|
| | |
|
| |
|
