| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
I plan to introduce logic to "reset" the server between individual tests,
which is currently triggered by the lack of any connections. This is the only
test that has a point where no clients are connected, and it's not necessary,
so I changed it to keep the connection open for the duration of the test.
|
| |
|
|
| |
This is a newly added field, and we expect to see it in these places now.
|
| |
|
|
|
| |
publisher is no longer included by default in broadcasts, but configured via
pubsub#itemreply instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previous behaviour:
- publisher was always included in PEP notifications
- publisher was never included in get_items requests
New behaviour:
- publisher is included in both notifications and retrieval if
itemreply == publisher
- publisher is not ever included if itemreply ~= publisher
|
| |
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This combines the two most common store types, which modules often end up
opening with both interfaces separately anyway.
As well as combining them, I've taken the opportunity to improve some of the
method names to make them clearer.
|
