fix: send correct connection scopes for client #20312
Merged
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
github-actions
bot
added
area: server
kekachmar
approved these changes
Mar 27, 2024
znewton
added a commit
to znewton/FluidFramework
that referenced
this pull request
May 16, 2024
## Description
When a client joins with AzureClient, it will always try to join in
`write` even if it only has `read` permissions according to its token
claims. On the server (Nexus Lambda), we handle that correctly by
creating a read-scoped connection. However, the server would incorrectly
handle client details and send connection info like this:
```js
socket.emit("connect_document_success", { /* ... */, mode: "read");
// ...
socket.emitToRoom(
"tenantId/documentId",
"signal",
{
/* ... join signal message ...*/,
client: { /* ... */, mode: "write"
});
```
I'm not sure about the specifics of what's happening on the client, but
when testing read client Audience and Signals usage in microsoft#20042, I
realized that the read client audience is not working appropriately
without this change. My understanding is it's because Audience is trying
to use Quorum (Join Ops) instead of Join Signals because the Join Signal
client details said `{ mode: "write" }` even though Connection details
said `{ mode: "read" }`
znewton
added a commit
that referenced
this pull request
May 17, 2024
## Description T9s v4 doesn't have the Quorum scrubbed users fix, and is also missing the fix for correct Read/Write scopes on socket connection. Cherry-picking some commits: --- ### server: cover edge cases for scrubbed checkpoint users (#20259) 6718a9a --- ### server: provided user was not an azure user fixes (#20150) 786abfa --- ### server: fix mutable quorum snapshot (#20329) 5de9472 --- ### fix: send correct connection scopes for client (#20312) 7d07fc5
RishhiB
pushed a commit
to RishhiB/FluidFramework-1
that referenced
this pull request
Jul 18, 2024
## Description microsoft#20914 disabled a few Azure E2E tests because they were timing out in T9s due to a T9s bug that was fixed in microsoft#20312. That bug has been patched into T9s v4 and was also released in T9s v5. We can enable those tests now. Validated locally that these pass by running `pnpm test`
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.
Description
When a client joins with AzureClient, it will always try to join in
writeeven if it only hasreadpermissions according to its token claims. On the server (Nexus Lambda), we handle that correctly by creating a read-scoped connection. However, the server would incorrectly handle client details and send connection info like this:I'm not sure about the specifics of what's happening on the client, but when testing read client Audience and Signals usage in #20042, I realized that the read client audience is not working appropriately without this change. My understanding is it's because Audience is trying to use Quorum (Join Ops) instead of Join Signals because the Join Signal client details said
{ mode: "write" }even though Connection details said{ mode: "read" }