-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filter out rooms from the room directory being served to other homeservers when those rooms block that homeserver by their Access Control Lists. #16759
Merged
Merged
Changes from 1 commit
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
5413007
Pass `from_federation_origin` down into room list retrieval code
reivilibre 7c0354b
Don't cache /publicRooms response for inbound federated requests
reivilibre efc6966
fixup! Don't cache /publicRooms response for inbound federated requests
reivilibre f7a2078
Cap the number of /publicRooms entries to 100
reivilibre a937f08
Simplify code now that you can't request unlimited rooms
reivilibre f969202
Filter out rooms from federated requests that don't have the correct ACL
reivilibre c04dff6
Request a handful more when filtering ACLs so that we can try to avoi…
reivilibre d2ad5b9
Newsfile
reivilibre b2cab24
Correctly emit `prev_batch` even if no results found in this batch
reivilibre db6a030
Add a test
reivilibre f260a7e
Use (0, empty room ID) as first-from-last pagination token, not the w…
reivilibre a51b959
Change log message (and move to DEBUG since it is fairly inappropriat…
reivilibre File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this an existing bug or is this somehow caused by the new filtering? I'm somewhat failing to see why we need to add this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is an existing bug. I hit it during testing and thought it was suspicious enough it was worth fixing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right. If
first_considered_room
is None then doesn't that mean that we have reached the end of the list and there are no more rooms? And if so then can we not reusesince_token
for the bound?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the previous chunk had rooms
!A
,!B
,!C
then (from memory) you get a next_chunk token saying!C
. The query that follows for the next request has a bound of> !C
.To go back to the prior chunk again, you need the query to have a bound of
< !D
. But if we have an empty chunk, we don't have any known room ID to stand in for!D
, hence the idea of cheekily constructing a fake one"!C\x01"
...If we give the
since_token
of!C
back, then going back to the prior chunk will only return!A
,!B
as rooms.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, yes I see. Has to be said that I'm not a huge fan of just chucking a byte on the end, but I suppose it works.
Can we use the
RoomListNextBatch(0, "")
since we know we're at the end? Or maybe we should always use thesince_token
for the prev batch and change the equality bounds on the DB query to avoid all this?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
those are a bit cleverer, yeah.
RoomListNextBatch(0, "")
sounds like a reasonable idea to me. I think flipping the bounds would also have been fine but I know there is scope to mess that up fairly easily...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup fair. I think your solution would have worked fine, but might just cause confusion having invalid room IDs in it, I dunno 🤷 Thanks for changing