Redo BroadcastChannel partitioning using channel name altering approach.
Chromium change: https://chromium.googlesource.com/chromium/src.git/+/61e816d489f1f574b609435922de3a48334c7b8d commit 61e816d489f1f574b609435922de3a48334c7b8d Author: Andrew Williams <awillia@google.com> Date: Mon Nov 1 04:41:04 2021 +0000 BroadcastChannel: Partition using StorageKey instead of Origin This CL updates the BroadcastChannel implementation so that partitioning is done by StorageKey instead of Origin. To facilitate this, it also changes the way in which Mojo messages are sent to preserve per-thread message ordering (as required by the BroadcastChannel specification). Previously, a shared, per-thread Remote was used to send messages from the renderer to RenderProcessHost on the browser side. This message would contain the origin, which the browser code would verify was accurate, and would then be used to establish the channel connection. This approach presents a challenge when switching to StorageKey, in that there's not a way to have the renderer send the StorageKey and have the browser verify it at the process level. This CL removes the origin from the message definition and replaces the RenderProcessHost handler (BroadcastChannelProvider instance) with separate ones for RenderFrameHostImpl, DedicatedWorkerHost, SharedWorkerHost, and ServiceWorkerHost instances. These new handles associate incoming connection attempts with their StorageKeys, allowing partitioning to be done without any information directly provided by the renderer. Shared per-thread Remotes are still used for workers to send messages to their corresponding host instance's BroadcastChannelProvider, and for frames a channel-associated interface is used to ensure that renderer messages are received in-order by the corresponding RenderFrameHostImpl. For more details, see the "Partitioned BroadcastChannel Design" document: https://docs.google.com/document/d/1CchMLU8QmDEx_tA0y57qLyQWvaTT3dlWF-4P_ncc06E/edit?usp=sharing Bug: 1239274
This commit is contained in:
committed by
mkarolin
parent
fa39c93443
commit
43ba430268
+10
-14
@@ -3,26 +3,22 @@
|
||||
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
|
||||
* You can obtain one at http://mozilla.org/MPL/2.0/. */
|
||||
|
||||
#include "third_party/blink/public/mojom/broadcastchannel/broadcast_channel.mojom-blink.h"
|
||||
#include "third_party/blink/renderer/core/frame/local_frame.h"
|
||||
#include "third_party/blink/renderer/modules/storage/brave_dom_window_storage.h"
|
||||
#include "third_party/blink/renderer/platform/weborigin/security_origin_hash.h"
|
||||
|
||||
// Ephemeral origin substitution is applied only to frame-based
|
||||
// Ephemeral origin channel name altering is applied only to frame-based
|
||||
// ExecutionContexts. This is fine because any Worker-based context still
|
||||
// wouldn't be able to communicate with a frame in both directions because a
|
||||
// frame-based BroadcastChannel will use an ephemeral origin instead of the one
|
||||
// the worker is using.
|
||||
#define ConnectToChannel \
|
||||
Version_; \
|
||||
{ \
|
||||
LocalDOMWindow* window = DynamicTo<LocalDOMWindow>(execution_context); \
|
||||
if (window) { \
|
||||
if (auto* origin = GetEphemeralStorageOrigin(window)) { \
|
||||
origin_ = origin; \
|
||||
} \
|
||||
} \
|
||||
} \
|
||||
provider->ConnectToChannel
|
||||
#define GetRemoteNavigationAssociatedInterfaces \
|
||||
should_send_resource_timing_info_to_parent(); /* no-op */ \
|
||||
if (auto* origin = GetEphemeralStorageOrigin(window)) { \
|
||||
name_ = name_ + String::Number(SecurityOriginHash::GetHash(origin)); \
|
||||
} \
|
||||
frame->GetRemoteNavigationAssociatedInterfaces
|
||||
|
||||
#include "../../../../../../../third_party/blink/renderer/modules/broadcastchannel/broadcast_channel.cc"
|
||||
|
||||
#undef ConnectToChannel
|
||||
#undef GetRemoteNavigationAssociatedInterfaces
|
||||
|
||||
Reference in New Issue
Block a user