Cross-origin iframe access

[superhawk610]

Cross-origin iframe access

[plitewaikato]

Thanks @superhawk610, I managed to get around this issue by making the error invisible by modifying the channel.css file. :)

[plitewaikato]

I'm seeing this error with Dashboards that I previously used with Dashkiosk and Chromecasts without X-Frame issues, so it must be possible. But I'm not too bothered as the workaround(s) seem fine.

…

On Tue, Jan 16, 2018 at 3:50 AM, Aaron Ross ***@***.***> wrote: The more I look around, the more it seems like there's no consistent way to accomplish this client-side. I think the correct solution is to have the server perform an OPTIONS request when saving the channel and throwing up a warning if it finds any problematic headers, such as X-Frame-Options or the like. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKQJEcf-h3g4HPVTn7wOGyl2HhR7aqhJks5tK2WZgaJpZM4RZtFL> .

[superhawk610]

One more thing to try is the X-Frame-Options header for your dashboard page, make sure it's set to the following:

X-Frame-Options: ALLOW-FROM http://{multicast-ip:port}

Can you try loading the device's display on your desktop browser (click Preview on the Device entry from the Devices page) and verify that it loads correctly there? If it doesn't, what error messages do you get in the console?

Additionally, I've had some issues in the past with the * not being sufficient for the control origin header, so you can also try

Access-Control-Allow-Origin: http://{multicast-ip:port}

Make sure not to include a slash at the end, so it should look something like this

Access-Control-Allow-Origin: http://192.168.10.10:3944

Finally, just to make sure it's actually a CORS issue and not something else entirely, can you verify that you are able to create a channel with another URL (such as one of the two built-in channels) and display it correctly on a connected device?

[plitewaikato]

I have the same issue with my dashboards. The channel loads correctly, but that annoying banner appears over the top. Any way to simple disable the error reporting?

[jonty-comp]

@superhawk610 Thanks for the very quick reply!
I've tried setting the IP specifically in both Access-Control-Allow-Origin and X-Frame-Options and it doesn't seem to have made any difference, unfortunately.

Here's my local Firefox dev tools when previewing the device from Multicast:

And here's Chrome's inspector connected directly to the Chromecast:

It's interesting that it says the X-Frame-Options header is invalid, since I cross-checked it with MDN and it looks fine!

The Nyan built-in channel displays on the TV and in my browser just fine with no error message.
In the meantime I've commented out the bit of code that displays the error, but obviously something is still fishy!

[superhawk610]

@jonty-comp looks like Chrome does not support the ALLOW-FROM syntax for X-Frame-Options, only DENY and SAMEORIGIN. Huh.

Does the page load correctly, it's just the warning message displaying incorrectly? I think my code for checking if an iframe is blocked due to CORS protection is faulty. Here's the relevant portion:

function checkFrame(frame) {
  var html,
    failed = false
  try {
    var doc = frame.contentDocument || frame.contentWindow.document
    html = doc.body.innerHTML
  } catch (e) {
    failed = true
  }

  if (!html) failed = true
  if (failed)
    displayError('Frame loading blocked due to cross-origin prevention')
}

It attempts to fetch the document body of each iframe on the page, which, if successful, should prove that it loaded correctly. There should be a better way to do this, but as far as I can tell there is no built-in method of communicating with the browser to check if a request was blocked due to CORS or not. Any suggestions?

@plitewaikato until we can get a permanent fix, you can disable errors by making this change:

# app/lib/connection.js
addError: (device, message) => {
+  return
  // you can pass a tag directly instead of a device

[jonty-comp]

Yes, the page itself loads fine, and i've gotten around the problem for now by commenting out the check rather than the error display, but obviously it would be nice to find a proper solution.

From a quick googling it seems like document.onload might work for checking if the iframe is loaded, or perhaps there's some way related to how you wanted to catch console errors from the chromecast back to the server.

[superhawk610]

The more I look around, the more it seems like there's no consistent way to accomplish this client-side. I think the correct solution is to have the server perform an OPTIONS request when saving the channel and throwing up a warning if it finds any problematic headers, such as X-Frame-Options or the like.

[bugtoo]

We are seeing the same issues and most dashboard are not loading correctly. If we use the multicast version of october 7th the issue is not present. Any ideas?

[superhawk610]

@bugtoo can you reply/PM me with more specifics about how they're not loading correctly? Quite a bit has changed since the 1.0 release last October. If you're just having an issue with the "Frame loading blocked" error message, you can disable error reporting until a permanent fix is released using this method.

[superhawk610]

I think the correct solution is to have the server perform an OPTIONS request when saving the channel and throwing up a warning if it finds any problematic headers, such as X-Frame-Options or the like.

I'll implement this in the next major release.

EDIT: Tracking this via #46.

[superhawk610]

This issue is being incorporated into the v3.0 release milestone.