| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| |
| | |
This is a convenience function, and there is currently no module-specific code
required to implement it. Not using 'self' is to be expected.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is a common pattern for modules to do something like check for
prosody.start_time, and execute code immediately if it is present, or wait for
the server-started event if it isn't yet. For example, this allows you to run
code after all other modules/hosts have been loaded, that are going to be
loaded.
Such code can now be replaced with a simple call to this method.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To avoid a race where server-started fires before the promise function body is
run (on next tick), I moved server-started to fire on the next tick, which
seems sensible anyway.
Errors are logged, I'm not sure if we ought to be doing something more here.
I'm sure we'll find out.
|
| |
| |
| |
| |
| | |
Only supporting exact match on full JID isn't helpful if you want to
list sessions per host or user.
|
| |
| |
| |
| | |
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).
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current method logs scary "access denied" messages on failure - this is
generally very useful when debugging access control stuff, but in some cases
the call is simply a check to see if someone *could* perform an action, even
if they haven't requested it yet. One example is determining whether to show
the user as an admin in disco.
The 'peek' parameter, if true, will suppress such logging.
The :could() method is just a simple helper that can make the calling code a
bit more readable (suggested by Zash).
|
| |
| |
| |
| |
| |
| |
| | |
We expect every session to explicitly have a role assigned. Falling back to
any kind of "default" role (even the user's default role) in the absence of
an explicit role could open up the possibility of accidental privilege
escalation.
|
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Also some comment headers and missing properties
|
| |
| |
| |
| |
| | |
If this object key exists then this schema must validate against the
current object. Seems useful.
|
| |
| |
| |
| | |
If this field exists, then these fields must also exist.
|
| |
| |
| |
| |
| |
| | |
Should be able to roundtrip trough serialization. Also nice for debug
and logging purposes where you might want more details than what the
__tostring method provides.
|
| |
| |
| |
| |
| |
| | |
Enables util.serialization to turn Sets into a representation that can be
deserialized with an environment trick, i.e. `set{"a","b"}`. Also useful
for debug purposes.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This was implied with the "debug" preset and does nice things like turn
util.set objects into "set{a,b,c}" instead of the quite verbose thing
you get otherwise.
|
| |
| |
| |
| |
| |
| |
| | |
Improves serialization of function references especially, the built-in
default handling of that in util.serialization is not the most
informative. Now, along with the function metatable from util.startup,
the actual function can be found by filename and line number.
|
| |
| |
| |
| |
| | |
Mostly in order to avoid triggering the XML syntax highlighting in the
console logger.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Plan to use this for integration tests.
|