Fix forced reconnections for guests when the HPB is used #4028
Conversation
This file contains hidden or 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
When a reconnection is forced and the standalone signaling server is used the participant joins again the conversation to get a new session, and then the websocket to the standalone signaling server is closed, which causes the reconnection with the signaling server. However, when the participant is a guest and joins again the previous session gets a "disinvite" message, which causes the browser to be redirected to the main Talk page. Due to this, now the "disinvite" message will be ignored when a forced reconnection is started until the socket has reconnected. It seems that the "disinvite" message will always be delivered before the request to rejoin a conversation returns, so the flag could be disabled as soon as the request returned instead of when the socket is connected. However, disabling it once the socket has connected again is also logical and seems more future proof. In any case, as the "disinvite" message is ignored that means that if a participant is actually kicked out from the conversation while performing a forced reconnection the browser will not be aware of it and a wrong UI would be shown. However, the chance of that happening is quite low. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
danxuliu
added
3. to review
bug
feature: signaling 📶
Member
Author
|
/backport to stable19 |
3 tasks
nickvergessen
approved these changes
Aug 20, 2020
nickvergessen
deleted the
fix-forced-reconnections-for-guests-when-the-hpb-is-used
branch
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.
This fixes a regression introduced in eba73a3
When a reconnection is forced and the standalone signaling server is used the participant joins again the conversation to get a new session, and then the websocket to the standalone signaling server is closed, which causes the reconnection with the signaling server. However, when the participant is a guest and joins again the previous session gets a
disinvitemessage, which causes the browser to be redirected to the main Talk page.Due to this, now the
disinvitemessage will be ignored when a forced reconnection is started until the socket has reconnected. It seems that thedisinvitemessage will always be delivered before the request to rejoin a conversation returns, so the flag could be disabled as soon as the request returned instead of when the socket is connected. However, disabling it once the socket has connected again is also logical and seems more future proof.In any case, as the
disinvitemessage is ignored that means that if a participant is actually kicked out from the conversation while performing a forced reconnection the browser will not be aware of it and a wrong UI would be shown. However, the chance of that happening is quite low.For a proper handling it would be probably better to fix this by taking into account the
reasonfield in thedisinvitemessage. However, if I am not mistaken the latest HPB version does not include yet that change, so it would work only for people running the master version of the signaling server.Also I have not checked either if it can be fixed somehow at the server level to prevent the
disinvitemessage from being sent in this case instead of ignoring it at the client level.How to test
OCA.Talk.forceReconnect()Result with this pull request
The guest reconnects.
Result without this pull request
The guest is redirected to the login page.