fix: run state res with old current state again

I'm a bit torn on the "auth check based on the current state of the
room". It can mean multiple things:

1. The state of the room before the homeserver looked at the event at
all. But that means if a message event from a user arrives, but we
didn't see their join event before, we soft fail the message (even
though we would find the join event when going through the auth events
of the event and doing state res)

2. The state of the room after doing state-res with the event and our
previous room state. We need to do this state resolution to find the new
room state anyway, so we could just use the new room state for the auth
check. The problem is that if the incoming event is a membership leave
event, the new room state does not allow another leave event. This is
obviously the wrong option.

3. The state of the room after doing state-res with the state **before**
the event and our previous room state. This will mean a lot more
calculations because we have to run state-res again

We used 2. before and now use 1. again
next
Timo Kösters 2021-05-17 10:58:44 +02:00
parent 8f27e6123b
commit ae41bc5067
No known key found for this signature in database
GPG Key ID: 24DA7517711A2BA4
1 changed files with 3 additions and 8 deletions

View File

@ -1126,9 +1126,9 @@ pub fn handle_incoming_pdu<'a>(
.map_err(|_| "Failed to load room state.".to_owned())?
.into_iter()
.map(|(k, v)| (k, Arc::new(v)))
.collect();
.collect::<BTreeMap<_, _>>();
fork_states.insert(current_state);
fork_states.insert(current_state.clone());
// We also add state after incoming event to the fork states
extremities.insert(incoming_pdu.event_id.clone());
@ -1229,12 +1229,7 @@ pub fn handle_incoming_pdu<'a>(
&room_version,
&incoming_pdu,
previous_create,
&new_room_state
.iter()
.filter_map(|(k, v)| {
Some((k.clone(), Arc::new(db.rooms.get_pdu(&v).ok().flatten()?)))
})
.collect(),
&current_state,
None,
)
.map_err(|_e| "Auth check failed.".to_owned())?;