Hi Team,
We’re integrating RealtimeKit plugins into our React portal and need help clarifying the supported launch contract and parent-origin allowlist behavior for the hosted plugins.
We are using the React sample as a reference:
https://github.com/cloudflare/realtimekit-web-examples/blob/main/react-examples/examples/plugins/sr…
Environment
React app using @cloudflare/realtimekit, @cloudflare/realtimekit-react, and @cloudflare/realtimekit-react-ui
Local portal origins tested:
http://localhost:4200/
Cloudflare hosted plugin URLs tested:
https://whiteboard-collabkit.cf-realtime.workers.dev/
https://docshare-collabkit.cf-realtime.workers.dev/
https://streamer-collabkit.cf-realtime.workers.dev/
We also tested a newer hosted plugin launch URL pattern like:
https://docshare.plugins.realtime.cloudflare.com/?auth=&parent=http%3A%2F%2Flocalhost%3A3…
What we are trying to do
We want to launch Whiteboard, DocShare, and Streamer from our portal using plugin iframe URLs, while passing the correct query params for the current RealtimeKit plugin implementation.
Observed behavior
DocShare can load in some cases, but Whiteboard and Streamer are blocked on our local origins.
Whiteboard shows:
“This whiteboard cannot be embedded on this domain.”
Streamer fails with iframe embed refusal / refused to connect.
We observed that Streamer returns a CSP with frame-ancestors that includes http://localhost:5173/ and Cloudflare example domains, but not http://localhost:4200/.
We also observed that Whiteboard appears to have its own runtime parent-origin allowlist and rejects unsupported domains.
Main questions
What is the currently supported launch URL contract for hosted plugins?
For the older *.cf-realtime.workers.dev plugin URLs, should we pass:
roomId
roomName
userId
userName
profilePicture
For the newer *.plugins.realtime.cloudflare.com URLs, should we pass only:
auth
parent
backend
pluginId
roomName
Or should both sets be passed together?
Is auth in the newer hosted plugin URL a plugin-specific authorization token, and is that now the preferred way to launch hosted plugins?
Is there a supported way to allow additional parent origins such as:
http://localhost:4200/
our production portal domain
If additional parent origins are not supported on the public hosted demo plugins, what is the recommended production path?
self-hosting the plugin apps
custom domain configuration
some dashboard allowlist setting
another supported mechanism
Are Whiteboard and Streamer intended to be demo/example-hosted only, or are they supported for embedding into customer-owned portal domains?
Expected behavior
We would like to embed the plugins in our portal on our own local and production origins, using the supported query param contract, without being restricted to localhost:5173 or Cloudflare example domains.
Example sanitized launch URL
https://docshare.plugins.realtime.cloudflare.com/?auth=<redacted_plugin_auth_token>&parent=http%3A%…
If helpful, we can also share our plugin iframe launch code and additional console/network details.
Hi Team,
We’re integrating RealtimeKit plugins into our React portal and need help clarifying the supported launch contract and parent-origin allowlist behavior for the hosted plugins.
We are using the React sample as a reference:
https://github.com/cloudflare/realtimekit-web-examples/blob/main/react-examples/examples/plugins/sr…
Environment
React app using @cloudflare/realtimekit, @cloudflare/realtimekit-react, and @cloudflare/realtimekit-react-ui
Local portal origins tested:
http://localhost:4200/
Cloudflare hosted plugin URLs tested:
https://whiteboard-collabkit.cf-realtime.workers.dev/
https://docshare-collabkit.cf-realtime.workers.dev/
https://streamer-collabkit.cf-realtime.workers.dev/
We also tested a newer hosted plugin launch URL pattern like:
https://docshare.plugins.realtime.cloudflare.com/?auth=&parent=http%3A%2F%2Flocalhost%3A3…
What we are trying to do
We want to launch Whiteboard, DocShare, and Streamer from our portal using plugin iframe URLs, while passing the correct query params for the current RealtimeKit plugin implementation.
Observed behavior
DocShare can load in some cases, but Whiteboard and Streamer are blocked on our local origins.
Whiteboard shows:
“This whiteboard cannot be embedded on this domain.”
Streamer fails with iframe embed refusal / refused to connect.
We observed that Streamer returns a CSP with frame-ancestors that includes http://localhost:5173/ and Cloudflare example domains, but not http://localhost:4200/.
We also observed that Whiteboard appears to have its own runtime parent-origin allowlist and rejects unsupported domains.
Main questions
What is the currently supported launch URL contract for hosted plugins?
For the older *.cf-realtime.workers.dev plugin URLs, should we pass:
roomId
roomName
userId
userName
profilePicture
For the newer *.plugins.realtime.cloudflare.com URLs, should we pass only:
auth
parent
backend
pluginId
roomName
Or should both sets be passed together?
Is auth in the newer hosted plugin URL a plugin-specific authorization token, and is that now the preferred way to launch hosted plugins?
Is there a supported way to allow additional parent origins such as:
http://localhost:4200/
our production portal domain
If additional parent origins are not supported on the public hosted demo plugins, what is the recommended production path?
self-hosting the plugin apps
custom domain configuration
some dashboard allowlist setting
another supported mechanism
Are Whiteboard and Streamer intended to be demo/example-hosted only, or are they supported for embedding into customer-owned portal domains?
Expected behavior
We would like to embed the plugins in our portal on our own local and production origins, using the supported query param contract, without being restricted to localhost:5173 or Cloudflare example domains.
Example sanitized launch URL
https://docshare.plugins.realtime.cloudflare.com/?auth=<redacted_plugin_auth_token>&parent=http%3A%…
If helpful, we can also share our plugin iframe launch code and additional console/network details.