Renamed `redacted_because_id` to `org.continuwuity.redacted_by` for proper namespacing; `get_unsigned_context` now lives in helpers.rs instead of `mod.rs`. The helper function also now explicitly wipes `unsigned` for `redacted_because` to avoid leaks (see comment).
I'm not sure how this doesn't cause more panics. When running an auth check on the create event during iterative auth checks, there's obviously no create event in the base state nor auth map, so the call to fetch_state() will return nothing and thus panic.
This just inserts the incoming event if it's a create event and there isn't an existing one in the auth state. It's not used for the create event checks anyway so this has no effect aside from plugging the panic.
Previously being a room creator short-circuited the `can_send_event`
check, which allowed creators to send state events "owned" (state key
starting with @ but not being the sender's user ID), in effect skipping
auth check 9 in v12 rooms. This removes that short circuit condition,
since `Infinite < Int` always returns false anyway, allowing the state
key check block to execute.
Fixes#2266
I have no idea how this can even happen and frankly I'm scared to look
however that's a problem for another time.
Panicking causes entire transactions to explode, this just makes one
event explode.
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.
The current `request_ip_source` setting only allows a single option.
While it does fall back to the peer IP if the header is missing as of !2003,
which likely covers a lot of regular use, only allowing a single option limits
the deployment options available to more advanced deployments.
Setups where internal and external traffic use different reverse proxies will
end up with the wrong IP and the implicitness of the fallback allows for
situations where the used IP is not the IP expected.
By introducing a setting that allows multiple options to be set,
this limitation is resolved and it becomes possible to have client IP resolution
behind different reverse proxies and also making it possible to decide if and/or
what the fallback should be.
If set, options are evaluated in order. If all fail, the request fails.