| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
`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).
|
| | |
|
| | |
|
| |
|
