6

We have an Ruby on Rail app that allows the user to save a number of video embed codes into a into our data model. The form allows the user to enter any number of embed codes, press submit and save everything to the database. The app then redirects the user to a page that has a list of all the embed codes.

This workflow works fine for IE, Safari, and Firefox.

On Chrome, however, the first time the page is loaded none of the videos appear on the page. I see the following error in the console, once for each video:

Refused to execute a JavaScript script. Source code of script found within request.

On subsequent page loads, the videos load fine and that error is not displayed.

When I view source, the page is reloaded for the view-source operation so I cannot tell if the source is coming through as expected.

When I inspect element on the block where the video should be, I see the following:

<iframe src="" width="400" height="225" frameborder="0">
  <html>
    <head></head>
    <body></body>
  </html>
</iframe>

This occurs for both the iframe style embed codes as well as for the "old-style" tag code for both YoutTube and Vimeo videos.

Related:

Community
  • 1
  • 1
Dave Jensen
  • 4,574
  • 1
  • 40
  • 45

2 Answers2

6

It's how Chrome prevents XSS (cross-site scripting), as your reference above.

When you submit your embed codes, and redirect to another page to display them, Chrome sees that the submitted embed codes (via HTTP POST))and the responded embed codes are the same, so it prevents to load them and displays error in the console.

When you refresh the page, no more HTTP POST submitted (because you redirected it before), so it should display correctly.

I have same problem, and I resolved it by auto reloading the page after it redirected.

Son Nguyen
  • 391
  • 4
  • 11
  • There's actually potentially a bug in Chrome. Not sure what the status of the bug is however. – Dave Jensen Dec 16 '11 at 04:37
  • 1
    A solution from the bug status report: Add `X-XSS-Protection: 0` to the response header. – nickvane Dec 05 '12 at 21:00
  • I added my workarround as answer, it's mostly the same approach (reloading) but i don't reload the whole page :) – Nick Russler Dec 28 '12 at 18:50
  • Son and Nickvane - thank you both! I had this issue on a Wordpress installment. Writers reported they could not add `iframe` elements. While testing it I found that it works only after a refresh. This was of course because the address of a page when previewed is `?preview=true...` - Adding the header `X-XSS-Protection: 0` on preview pages only worked flawlessly. I found this gist which seems to solve the same issue exactly on WP but I suggest modifying the condition a little before using it. https://gist.github.com/ocean90/3622298 – ido Aug 11 '13 at 22:21
1

I reload the iframes via javascript (with jquery) as workarround..

I therefore store the src elsewhere cause chrome removes it..

I added the url twice as src and src2, and reloaded then with src2.

I also gave all the iframes that need reloading a special class 'webkitIframeHack'.

<script type="text/javascript">
$(function(){
    if ($.browser.webkit) {
        $("iframe.webkitIframeHack").each(function(){
            $(this).attr('src', $(this).attr('src2'));
        });
    };
});
</script>

(I can't use html5 data-* attributes, i think they would be more fitted..)

Nick Russler
  • 4,608
  • 6
  • 51
  • 88