[WPB-6144] Prevent MLS one-to-one messaging for a blocking user (q1-2024) - no dependencies on the notification subsystem
#3922
Conversation
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
* Test: no MLS 1-to-1 when a connection is blocked * Test: a test with expected behavior after blocking the connection * Check if sending a msg to 1-to-1 and not connected * Add a changelog * WIP: Debugging a test failure * Update the confirming test * Revert "Check if sending a msg to 1-to-1 and not connected" This reverts commit c4af150. * WIP: generalise the Update.blockConv handler * Connections: Also block MLS one2one conv when blocking conn * Test: Parameterise over One2OneScenario * Add the missing connection ID in an internal endpoint * Wrap a function comment for readability * Introduce a Galley internal endpoint: blocking a qualified conversation * WIP: Check if an MLS 1-1 conv exists before blocking What is left to do is to make this check work for an MLS 1-1 conv that can be remote * Make upsertOne2OneConv always take a Conv ID Brig can determine this ID based on protocol of the conversation or read it from the DB. Inventing this in galley causes more trouble for having two One2One convs for proteus and mls. * WIP: Remove user from 1:1 MLS conv when they block someone * WIP: Remove mls clients on connection block * fixup! WIP: Remove mls clients on connection block * Make sure 1-1 conv is established before updating * Finalise the bug-confirming test * Remove debugging output from application code * Fix a changelog * Remove redundant constraints * Properly check if an MLS 1-1 conversation exists before blocking it * Remove more of unused code * Remove an unused connection ID in an internal Galley endpoint for blocking a conv --------- Co-authored-by: Akshay Mankar <akshay@wire.com>
zebot
added
the
ok-to-test
elland
reviewed
Mar 6, 2024
| case HTTP.statusCode (HTTP.responseStatus response) of | ||
| 403 -> pure False | ||
| 400 -> pure False | ||
| _ {- 200 is assumed -} -> do |
There was a problem hiding this comment.
Should we throw for other non-200 values?
There was a problem hiding this comment.
I think this did the job the way it is. I'm reworking this in a PR for unblocking a user, and there I take a finer grained approach.
Co-authored-by: Igor Ranieri Elland <54423+elland@users.noreply.github.com>
Co-authored-by: Igor Ranieri Elland <54423+elland@users.noreply.github.com>
pcapriotti
approved these changes
Mar 11, 2024
echoes-hq
bot
added
the
echoes: unplanned
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The PR obsoletes PR #3900.
This is a backport of PR #3889 and PR #3906 from
developtoq1-2024.Tracked by https://wearezeta.atlassian.net/browse/WPB-6144.
Checklist
changelog.d