| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This lines don't appear to do anything useful, and all tests pass when they
are removed. Discovered via mutation testing.
I added extra tests to exercise this code, because I wasn't certain that there
were no side-effects caused by removal. Everything appears to be fine, thanks
to the "pending" check at the start of promise_settle().
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We don't expose the policies directly, to force people to go through :may().
However, there are times when we really just need to know what policies a
role has inside it (e.g. for reporting or debugging purposes).
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously, if the first inherited role had no opinion, it returned false and
prevented further consultation of other inherited roles.
This bug was found thanks to the implementation of missing test cases
identified through mutation testing.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conversations 2.10.10 and earlier expect this to be literally 'true' and don't
recognise '1'. This leads to it not attempting resumption with Prosody at all
since this change was introduced in 36ba170c4fd0.
Thanks to Zash for noticing, debugging and diagnosing this issue.
This issue is fixed in Conversations commit 052c58f3 (unreleased at the time
of writing).
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This is a security improvement, to ensure that sessions authenticated using a
token (note: not currently possible in stock Prosody) are invalidated just
like password-authenticated sessions are.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Thanks Menel and Martin
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The use of the error helpers creates an `<error/>` child element
containing the error condition. This is however not allowed as per
XEP-0198, which specifies that the error condition is to be a direct
child of the `<failed/>` stream management element.
This has triggered a fun reconnect loop in aioxmpp where it was
reported by a user [1].
[1]: https://github.com/horazont/aioxmpp/issues/382
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Found this number in a hat.
Sleepy time. Good night.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This fixes the signature parsing and building to work correctly. Sometimes
a signature was one or two bytes too short, and needed to be padded. OpenSSL
can do this for us.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
New behaviour (muc_room_allow_persistent = true, the default):
- Parent host users are not restricted by default (prosody:user)
- Users without roles (by default that is non-admins, non-parent-host users,
and users on other servers) can no longer configure persistence by default.
muc_room_allow_persistent = false will restrict persistence to prosody:admin.
Parent-host users should not be restricted by default, and this can be
configured via the new roles/permissions options.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
change)
With this change and 427dd01f0864, room creation is now effectively restricted
to parent-host users by default. This is a better default than previous
Prosody versions (where room creation was not restricted).
The "local" option for restrict_room_creation is no longer used (any value
other than true/false won't change the default behaviour).
restrict_room_creation = true will grant prosody:admin the ability to create
rooms.
restrict_room_creation = false disables all permission checks.
Anything between these two can be achieved using custom roles and permissions.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
'host_user_role' is the default role of users who have JIDs on the "parent"
host (i.e. jabber.org users on conference.jabber.org). Defaults to
'prosody:user'.
'server_user_roles' is the default role of users who have JIDs on any active
host on the current Prosody instance. Default to nil (no role).
This finally allows better permissions splitting between host and server
users, which has previously been done (e.g. in MUC) with options like
'restrict_room_creation' and 'muc_room_allow_persistent'. Using roles makes
these permissions a lot more flexible, and easier for developers to integrate.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Non-admins don't have a role on MUC services by default. Not even
prosody:user. This meant they had no :create-persistent-room permission, even
if muc_room_allow_persistent was true (the default).
Now we only check the role permissions if persistent room creation is
restricted, otherwise we skip any permission checks, just like previous
versions.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This can happen to sessions before they are assigned a role
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
muppeth)
Fixes
Error in SQL transaction: Error executing statement parameters: ERROR: invalid input syntax for integer
This was handled for INSERT in 9524bb7f3944 but not SELECT.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It's now possible to bind during SASL2 negotiation.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Fixes a test failure on Lua 5.4 where ipairs("") does not produce an
error.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
In Lua 5.3 LUAL_BUFFERSIZE is a macro computed from sizeof and is thus
not known at pre-processing time, so this does not work.
Since Lua 5.1 is no longer supported, we can use luaL_prepbuffsize()
which is available from Lua 5.2
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Removes assumption that LUAL_BUFFERSIZE is known at pre-processing time,
which it is not in Lua 5.3 and 5.4, where it is a computed macro based
on sizeof.
Allocation of stack space is safer and faster, no need to worry about
luaL_prepbuffer failing to allocate memory and skipping free()
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The PASETO spec recommends - no, *requires* - that implementations enforce
type safety for keys, and e.g. do not pass them around as arbitrary byte
strings. Typed wrapper objects are recommended.
I originally followed this advice when starting the lib. However, key wrapping
and type safety is now also a feature of util.crypto. All we're doing is
duplicating it unnecessarily with this additional wrapper code.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Unfortunately there are only a few relevant ones, but they did help catch some
bugs.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Some changes/improvements in this commit:
- Default token lifetime is now 3600s (from 300s)
- Tokens are only validated once per upload
- "iat"/"exp" are handled automatically by util.jwt
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
To avoid every user of the library needing to add and verify expiry info, this
is now handled by util.jwt itself (if not overridden or disabled).
Issuing tokens that are valid forever is bad practice and rarely desired, and
the default token lifetime is now 3600s (1 hour).
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Except 'none'. Not implementing that one.
|
| | | | | | | | |
|
| | | | | | | | |
|