Previously, a transaction panicking in the handle() call would cause the
transaction to be indefinitely logged as "running" in the transaction
handler. This means subsequent transactions from the sending server
would be met with the "You're still sending me a txn!" 429 response,
forever, effectively causing defederation between the two servers, until
continuwuity is fully restarted.
I could just fix the known panics in the handle function and internal
calls, however there's so many subsystems that could reasonably panic
that it is just better to have a safer approach and ensure that the
handle call is infallible.
The token endpoint already refused grant types the client had not
registered, but reported it as `invalid_grant`. RFC 6749 section 5.2
reserves `invalid_grant` for an authorization grant which is "invalid,
expired, revoked, does not match the redirection URI used in the
authorization request, or was issued to another client", and defines
`unauthorized_client` for a client which "is not authorized to use this
authorization grant type".
Report the condition with the error code the specification assigns to it,
matching the device authorization endpoint.
The device authorization endpoint issued a device code to any registered
client, without checking that the client had registered the
`urn:ietf:params:oauth:grant-type:device_code` grant type. Such a client
could therefore start a device authorization flow and have the server
show an approval prompt to a user, even though the subsequent token
request was always going to be refused.
RFC 8628 section 3.2 states that, in the event of an error such as an
invalidly configured client, the device authorization endpoint responds
in the same way as the token endpoint specified in RFC 6749 section 5.2,
which defines `unauthorized_client` as "the authenticated client is not
authorized to use this authorization grant type".
Apply the same grant type check the token endpoint already performs, and
add the `unauthorized_client` error code it requires.
Fixes a potential issue where continuwuity correctly defaults to room v1
when encountering an unknown room version, but then fails to *stop*
processing when it encounters the room version it doesn't actually
understand.
On room creation, A list of initial state events may be provided that
should be submitted to the room after creation. These events
should be treated as any other state event and submitted to
the same checks.
With this change, state events submitted on room creation will be
submitted through the same helper as those through the usual endpoint.
The submission helper is moved to the timeline service to make it
available everywhere. This will be useful for implementing MSC4140
(issue #903).
roomuserid_lastnotificationread was mapped to userroomid_highlightcount
instead of its own table, so last_notification_read() read the highlight
count and reset_notification_counts clobbered the highlight table when
setting a read marker. Add the missing table definition and fix the alias.
timedout
Erwan Leboucher
Ginger
Michel-Marie MAUDET
Jacob Taylor
Renovate BotandGinger
new-years-eve
reaster