| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Except 'none'. Not implementing that one.
|
| | |
|
| | |
|
| |
|
|
|
| |
Now we can consistently apply the same tests to every algorithm, instead of
duplicating code.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
These are used by the RS*** and PS*** family of JOSE algorithms (e.g. in JWTs)
|
| |
|
|
|
|
|
|
|
|
|
| |
In many cases code will be either signing or verifying. With asymmetric
algorithms it's clearer and more efficient to just state that once, instead of
passing keys (and possibly other parameters) with every sign/verify call.
This also allows earlier validation of the key used.
The previous (HS256-only) sign/verify methods continue to be exposed for
backwards-compatibility.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
PASETO provides an alternative to JWT with the promise of fewer implementation
pitfalls. The v4.public algorithm allows asymmetric cryptographically-verified
token issuance and validation.
In summary, such tokens can be issued by one party and securely verified by
any other party independently using the public key of the issuer. This has a
number of potential applications in a decentralized network and ecosystem such
as XMPP. For example, such tokens could be combined with XEP-0317 to allow
hats to be verified even in the context of a third-party MUC service.
|
| |
|
|
|
| |
Specifically, ED25519 key generation/import/export, sign/verify operations,
and AES encrypt/decrypt.
|
| |
|
|
|
| |
The macros in this header allow creation of GC-managed objects from manually-
managed C alloc/free APIs.
|
| |
|
|
| |
...with opportunistic writes enabled.
|
| |
|
|
|
| |
The condition checked for s2sin but not s2sout, so would have ignored
bidi-enabled s2sout sessions. Components as well.
|
| | |
|
| | |
|
| |
|
|
|
| |
Some fiddling is required now in error_reply() to ensure the cursor is in the
same place as before this change (a lot of code apparently uses that feature).
|
| |
|
|
|
|
|
|
|
|
| |
The old behaviour of falling back to the component domain when it is missing
has been merged into the logic for the existing "validate_from_addresses"
option (which is strict by default).
ejabberd already rejects component stanzas with no 'from' (as the XEP
requires), and this has led to compatibility issues for components that were
seemingly working fine with Prosody.
|
| |
|
|
| |
See bd9e006a7a74
|
| |
|
|
| |
No other changes to account for.
|
| | |
|
| |
|
|
|
| |
This will allow us to return the success/failed as part of the SASL2 response,
and *then* perform the stanza sync as a second step.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
Fixes the same kind of issue as in 65563530375b but once and for all,
while improving similarity between incoming and outgoing connections.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
For luacheck, but it doesn't actually complain about this right now
|
| | |
| |
| |
| |
| | |
It used _G.print instead of the shell session print, which would
silently write to stdout
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
By creating the account first without a password it can't be used until
the role has set. This is most important for restricted accounts, as a
failure to set the role would lead to the account having more privileges
than indented.
|
| | | |
| | |
| | |
| | |
| | | |
This ensures that the store is not empty in case no password is
provided, so the underlying data storage won't consider the store empty.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Otherwise, create_user(username, nil) leads to the account being
deleted.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
It's not plural
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Goal: Introduce role-auth with minimal disruption
is_admin() is unsafe in a system with per-session permissions, so it has been
deprecated.
Roll-out approach:
1) First, log a warning when is_admin() is used. It should continue to
function normally, backed by the new role API. Nothing is really using
per-session authz yet, so there is minimal security concern.
The 'strict_deprecate_is_admin' global setting can be set to 'true' to
force a hard failure of is_admin() attempts (it will log an error and
always return false).
2) In some time (at least 1 week), but possibly longer depending on the number
of affected deployments: switch 'strict_deprecate_is_admin' to 'true' by
default. It can still be disabled for systems that need it.
3) Further in the future, before the next release, the option will be removed
and is_admin() will be permanently disabled.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rationale:
- Removes a bunch of code!
- We don't have many cases where an actor is not bound to one of our hosts
- A notable exception is the admin shell, but if we ever attempt to lock those
sessions down, there is a load of other work that also has to be done. And
it's not clear if we would need a global authz provider for that anyway.
- Removes an extra edge case from the necessary mental model for operators
- Sessions that aren't bound to a host generally are anonymous or have an
alternative auth model (such as by IP addres).
- With the encapsulation now provided by util.roles, ad-hoc "detached roles"
can still be created anyway by code that needs them.
|
| | | | |
|
| | | | |
|
| | | | |
|
