Skip to content

VNC-531 Refactor for enhanced uniqueness and consistency. - #211

Open
quickiwiki wants to merge 1 commit into
masterfrom
bugfix/VNC-531-framebuffer-port-relay-pairs-windows-by-unauthenticated-numeric-index
Open

quickiwiki wants to merge 1 commit into
masterfrom
bugfix/VNC-531-framebuffer-port-relay-pairs-windows-by-unauthenticated-numeric-index

Conversation

@quickiwiki

Copy link
Copy Markdown
Collaborator

No description provided.

Comment thread core/display.js
}
};
relayWorker.port.postMessage({type: 'secondary_ready', screenIndex});
relayWorker.port.postMessage({type: 'secondary_ready', screenID: this.screenID});

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Relay initialization remains tied to every registered index notification. Reindexing screens sends registered again, causing the secondary to open another worker connection. The PR removed the corresponding primary re-registration, leaving a stale pending room for that screenID

Comment thread app/port-relay-worker.js
port.onmessage = function (ev) {
const {type, screenIndex} = ev.data;
if (typeof screenIndex !== 'number')
const {type, screenID} = ev.data;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The UUID is observable. Secondary registration broadcasts screenID over a channel named solely from the page URL. Any same-origin context can subscribe, learn the UUID, then race secondary_ready. The worker still gives the framebuffer port to the first matching registration, reproducing VNC-531’s interception scenario.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants