| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
For mod_invites_register to apply on user creation.
|
| |
| |
| |
| |
| |
| | |
Part of an update to mod_invites and friends to the new authz and roles.
Invites with roles in the old way will need to be migrated, but with
invites often being short lived it is probably not a long-lived problem.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
By checking the password_updated_at for non-nilness before using it,
we avoid a nasty crash :-).
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This is another iteration on top of the previous sub-tokens work. Essentially,
the concept of a "parent token" has been replaced with the concept of a
"grant" to which all tokens now belong. The grant does not have any tokens
when first created, but the create_token() call can add them.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Properties of sub-tokens:
- They share the same id as their parent token
- Sub-tokens may not have their own sub-tokens (but may have sibling tokens)
- They always have the same or shorter lifetime compared to their parent token
- Revoking a parent token revokes all sub-tokens
- Sub-tokens always have the same JID as the parent token
- They do not have their own 'accessed' property - accessing a sub-token
updates the parent token's accessed time
Although this is a generic API, it is designed to at least fill the needs of
OAuth2 refresh + access tokens (where the parent token is the refresh token
and the sub-tokens are access tokens).
|
| | |
|
| |
| |
| |
| | |
Spaces, no hyphen, apparently.
|
| |
| |
| |
| |
| | |
Fixes that otherwise the user was created in a disabled state and left
as such.
|
| |
| |
| |
| |
| |
| | |
Idea here is to prevent a user from being created with the default role
if a different role was given, but that dance wouldn't be needed if no
role is provided.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Plan to use this for integration tests.
|
| |
| |
| |
| |
| |
| | |
This gives the broadcaster access to the node configuration, which is now
important for itemreply. It probably also fixes a bug with the notify_*
node config options?
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This matches ejabberd's behaviour, using the 'pubsub#itemreply' config option.
Although the current definition of this option in the specification is not
as clear as it could be, I think matching what existing deployments do is the
best option to resolve the ambiguity and reduce fragmentation.
We should update the spec to be clearer about how to use and interpret this
option.
The 'expose_publisher' option for mod_pubsub is now an override (always expose
or never expose). If unset, it will use the per-node config (which defaults to
not exposing).
Thanks to Link Mauve, edhelas and goffi for sparking this feature.
|
| |
| |
| |
| |
| |
| |
| | |
Errors in sha256 becasue `token_secret` is nil since it was not passed
to _get_validated_token_info().
Looks like a simple oversight in ebe3b2f96cad
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new format has the following properties:
- 5 bytes longer than the previous format
- The token now has separate 'id' and 'secret' parts - the token itself is no
longer stored in the DB, and the secret part is hashed
- The only variable length field (JID) has been moved to the end
- The 'secret-token:' prefix (RFC 8959) is now included
Compatibility with the old token format was not maintained, and all previously
issued tokens are invalid after this commit (they will be removed from the DB
if used).
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Following the new behavior in auth_internal_hashed (c8f59ce7d3cf), the account
will be created and disabled, instead of returning an error telling password
being nil when calling saslprep().
Note that mod_auth_internal_plain does not have full support for
enabled/disabled accounts, but that may be fixed in subsequent commits.
|
| |
| |
| |
| |
| | |
Why did it call a function defined in the same module through
usermanager?
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Could be useful for e.g. #1772
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Made it reject the primary role since it compares against a non-existent
field, i.e. nil.
|
|\| |
|
| | |
|
| |
| |
| |
| | |
Why was this module loaded? Now you can find out!
|
| |
| |
| |
| |
| |
| |
| |
| | |
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?
|
| |
| |
| |
| | |
`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.
|
| |
| |
| |
| | |
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.
|
|\| |
|