| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
Allows modules explicit dependencies upon its availability
|
| |
|
|
|
| |
Now both require"util.foo" and require"prosody.util.foo" should be
equivalent.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
namespaces
Prevents modules being initialized twice, ensuring that
require"prosody.util.foo" == require"util.foo"
|
| |
|
|
|
|
|
| |
Nice to drop that patch.
Will allow loading this to do something both when installed under a
prosody directory or from a source checkout.
|
| |
|
|
|
|
|
|
|
|
| |
Actually `hg mv`-ing all the files is disruptive, basically breaking
everything from rebasing all my WIP draft commits to the package
building. So instead, what if we didn't and instead rewrote package
names as they are `require()`-d?
Debian packages produced by the Prosody are already installed into this
structure so much will Just Work if all require calls are updated.
|
| |
|
|
|
| |
Why did it call a function defined in the same module through
usermanager?
|
| |
|
|
|
|
|
| |
For potential future use.
Used for logging into a different account than the one used for
authentication.
|
| |
|
|
| |
Absolute references, weird fractions, unevaluatedProperties???
|
| |
|
|
| |
These seem to be using absolute URI references, Not Yet Implemented
|
| | |
|
| | |
|
| |
|
|
| |
Partly copied from util.sasl.scram and then reduced a bit.
|
| |
|
|
|
|
| |
To keep them sorted.
Not pedantic at all!
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
This allows token-aware things to access extra information about the
authentication, such as when the token is due to expire and the attached
custom 'data'.
|
| | |
|
| | |
|
| |
|
|
| |
Could be useful for e.g. #1772
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Turns out we had a definition of that already
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |\ |
|
