CORS Errors on the official IMA reference implementations

3,385 views
Skip to first unread message

DFP User

unread,
May 5, 2017, 2:36:25 AM5/5/17
to Interactive Media Ads SDK
Hi,

The Google AdSense for Video approval team rejected my IMA SDK implementation because of CORS errors in the JavaScript Console.

Having searched this forum in detail, I see many other web-developers struggling with implementing CORS headers correctly when using the Google HTML5 SDK.  Most of the advice on this forum seems to point the developer towards the CORS advice in the IMA Documentation.  However, this advice is only relevant for the developers of an VAST ad server.  It is entirely irrelevant to a web-developer who wants to use Google IMA on their page using Google DFP, AdSense or Ad Exchange.

I need to get to a point where I have a clean JavaScript console log to get AdSense for Video approval.  So I head off to the IMA reference implementations...

When I look at the reference implementations of the Google IMA HTML5 SDK, the JavaScript console creates several CORS errors.  This happens on latest versions of Chrome 58/Mac and Safari 10/Mac.

For example...

The reference implementation of the Google Video Suite Inspector using the sample tag, Google Chrome...

XMLHttpRequest cannot load https://googleads.g.doubleclick.net/pagead/id. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.youtube.com' is therefore not allowed access.

Ok, lets now strip the VAST inspector back to the Google AppSpot where the page is hosted.  This time, we get a different CORS error.

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://www.youtube.com') does not match the recipient window's origin ('https://imasdk.googleapis.com').

XMLHttpRequest cannot load https://googleads.g.doubleclick.net/pagead/id. Redirect from 'https://googleads.g.doubleclick.net/pagead/id' to 'https://googleads.g.doubleclick.net/pagead/id?dpt=1' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.youtube.com' is therefore not allowed access.

The Google IMA HTML5 SDK video.js reference implementation (albeit hosted on Github.io where you have no control over the server config) generates the following errors in Google Chrome...
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://www.youtube.com') does not match the recipient window's origin ('https://imasdk.googleapis.com').

XMLHttpRequest cannot load https://googleads.g.doubleclick.net/pagead/id. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.youtube.com' is therefore not allowed access.
It appears even the reference implementations of the Google IMA HTML5 SDK create CORS errors in modern desktop browsers.

If using a 3rd party ad server, it is accepted that the 3rd party ad server should play nice and follow the advice on both the IMA Documentation and the IAB VAST 3.0 Specification.
Access-Control-Allow-Origin: <origin header value>
Access-Control-Allow-Credentials: true

However, for all the ad tags used in the above official samples, the IMA Team's DFP Server does adhere to this recommendation.  The CORS settings on the DFP Ad Server is behaving as expected (tested using cURL in the snippet below).

 
HTTP/1.1 200 OK
P3P: policyref="https://googleads.g.doubleclick.net/pagead/gcn_p3p_.xml", CP="CURa ADMa DEVa TAIo PSAo PSDo OUR IND UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"
Timing-Allow-Origin: *
Google-MediationGroup-Id: -2
Access-Control-Allow-Origin: foobar
Access-Control-Allow-Credentials: true
...[SOME OTHER STUFF REMOVED IN THE INTERESTS OF BREVITY] 
Transfer-Encoding: chunked

This means that the errors within the reference implementations are being caused by one or more of the following:
  1. The hosting of the page where the app is hosted (this is the only actor in the system under the web-developer's control)
  2. https://imasdk.googleapis.com API/SDK
  3. https://www.youtube.com
  4. The Browser
If the issue is (1), please can we have some advice as to how a web-developer should configure their CORS headers on their servers, or the best practice when making a XMLHttpRequest to avoid the errors when using the IMA SDK.

If the issue is (2), please can the IMA SDK / Google APIs team take a look?

If the issue is (3), please can you ask the YouTube team to fix their CORS configuration?  I don't pretend to understand the inner workings of the IMA SDK, but is seems crazy for the IMA SDK to be using using a YouTube-domain hosted video player hosted on an external resource.  That is over-complexificating [sic] by adding another actor into the already complex relationship between the Browser / Page / IMA SDK and Ad Server.  The CORS configuration between the main parties is complex enough without dragging the YouTube team into the equation.

Please can we have a reference implementation which does not generate errors in a modern browser?  Or at least some Best Practice documentation as to how a web developer should configure CORS on the page/host that uses IMA HTML5 SDK, DFP Ad Server and Chrome browser?

Thanks!

Chris Feldman (IMA SDK Team)

unread,
May 5, 2017, 2:38:36 PM5/5/17
to Interactive Media Ads SDK
Hi,

I'm not able to reproduce the issues that you're seeing with our reference implementations (screenshots attached). If you're still having issues with the VSI, can you provide us with detailed steps for reproducing the issue? You can also send Charles Network Logs if you have them available. For CORS configuration, all that should be necessary is in our documentation.

Regards,
Chris Feldman
IMA SDK Team
Screen Shot 2017-05-05 at 2.20.16 PM.png
Screen Shot 2017-05-05 at 2.17.17 PM.png

DFP User

unread,
May 5, 2017, 6:54:00 PM5/5/17
to Interactive Media Ads SDK
Thanks Chris Feldman,

I'll grab screenshots and post.


 For CORS configuration, all that should be necessary is in our documentation.

I have seen this advice across the forum, but I'm afraid it is rather misleading.  The CORS documentation that you link to describes how a VAST Ad Server (DFP, Ad Exchange, AdSense, SpringServe, Tremor, SpotX, YuMe, Vindico etc) should behave and is of no use whatsoever to a web-developer who is trying to implement the IMA on a web page, other than to know that their 3rd party ad-serving partner is adhering to the IAB VAST 3.0 recommendation for CORS.  That advice appears in the IAB VAST 3.0 Specification for those implementing an VAST Ad Server.  But it is no relevance to how a web-developer would implement an app using the IMA SDK.  Please have another read of it and you will see what I mean.

Cross-Origin-Resource-Sharing (CORS) for VAST
Modern browsers apply same-origin security restrictions to JavaScript network requests, meaning that a web application running from one origin cannot retrieve data served from a different origin. For VAST, this security restriction prevents JavaScript XMLHttpRequests made from JavaScript VAST rendering code from reading a VAST ad response served from a different origin. 
This security restriction is meant to prevent issues where one origin is able to read data from another origin that a user may be logged into without that user's permission. The restriction poses problems for VAST served in a JavaScript environment because an ad server is often on a different domain than the ads player.
Cross-Origin Resource Sharing (CORS) headers is a W3C draft specification meant to allow sharing across different origins. To be servable in a JavaScript environment a VAST ad server's response must include the following HTTP CORS headers:
Access-Control-Allow-Origin: <origin header value>     
Access-Control-Allow-Credentials: true
This HTTP header allows an ads player on any origin to read the VAST response from the ad server origin. The value of Access-Control-Allow-Origin: should be the value of the Origin header sent with the ad request. The Access-Control-Allow-Credentials: header will ensure that cookies will be sent and received properly.
For more information, refer to the W3C Draft Specification on Cross-Origin Resource Sharing

DFP User

unread,
May 5, 2017, 8:23:17 PM5/5/17
to Interactive Media Ads SDK
I was able to reproduce the errors (both on my machine and my colleague's machine).

1.  Open Chrome
2.  Create a new Person in Chrome (to bypass any extensions you have installed and avoid any ambiguity)
4.  Open the JavaScript Console
5.  Refresh the page (This is the important bit.  The Chrome JavaScript Console does not show any errors that have occurred *before* the console was opened)
6.  See the CORS errors in JavaScript console.  You do not even have to get to the point of executing the sample ad.  They occur at pageload.  See attached screenshot.

Following https://developers.google.com/interactive-media-ads/docs/sdks/html5/ads#cors will have no bearing on the outcome of these errors.

I hope that helps.

Thanks

A DFP User

IMAVastInspector_JavaScriptConsoleErrors.png

Chris Feldman (IMA SDK Team)

unread,
May 8, 2017, 3:18:59 PM5/8/17
to Interactive Media Ads SDK
Hi,

Thank you for bringing this to our attention. I was able to replicate the error and will show this to the rest of the team. However, as no ad has been served when this error is fired, this is just a general issue with the page. It isn't related to the IMA SDK. If you've seen CORS errors from serving a properly configured tag on one of our reference implementations then please share the tag and steps to reproduce the issue. I would be happy to look further into the issue.

To your broader issue, if the CORS header on the ad server is configured correctly then the SDK should supply all the proper parameters to avoid an error. There is no overhead needed on your part. 

Regards,
Chris Feldman
IMA SDK Team

DFP User

unread,
May 10, 2017, 11:08:00 AM5/10/17
to Interactive Media Ads SDK

Thanks for taking a look at the Video Suite Inspector page, Chris Feidman.  The Video Suite Inspector is one of the yardsticks of the industry, so as a community, we need that page to behave without issue.  I also see CORS errors when playing back the ad.




If you've seen CORS errors from serving a properly configured tag on one of our reference implementations then please share the tag and steps to reproduce the issue. I would be happy to look further into the issue.

As a different example, lets take a look at the Advanced Video.js-IMA Demo, hosted by Github Pages.

I'm using Safari as an example because it does a reasonable job of representing both desktop and mobile behavior.  I'm using HTTPS because that is the right thing to do.

Browser: Safari 10.1 (no extensions installed), OS X 10.12.4
  1. Open Safari (Quit and Open a fresh browser instance).
  2. After loading any *.html page, Open the Console (Opt-Cmd-I)
  3. Clear your browser's cookies.
  4. Develop > Empty Caches (assuming you have enabled the Develop menu enabled in Safari)
  5. Visit https://googleads.github.io/videojs-ima/examples/advanced/index.html
  6. Load the Sample Ad Tag
  7. Edit the schema of the Sample Ad Tag to be https://pubads.g.doubleclick.net (or just use //pubads.g.doubleclick.net relative schema)
  8. Start the advert.
  9. See CORS errors in the logs.  Screenshot attached.
There is certainly something weird going on between youtube and googleapis, and this is within the inner workings of the SDK.

[Error] Unable to post message to https://www.youtube.com. Recipient has origin https://imasdk.googleapis.com.
postMessage
C (www-widgetapi.js:119:451)
H (www-widgetapi.js:116)
(anonymous function)

However, it is not just Safari, attached is a screenshot of Chrome 58 with a similar-looking, but different CORS error.

XMLHttpRequest cannot load https://googleads.g.doubleclick.net/pagead/id. Redirect from 'https://googleads.g.doubleclick.net/pagead/id' to 'https://googleads.g.doubleclick.net/pagead/id?dpt=1' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.youtube.com' is therefore not allowed access.


Advanced Video-js IMA Demo, Safari 10.1, HTTPS



Advanced Video-js IMA Demo, Chrome58, HTTPS



To your broader issue, if the CORS header on the ad server is configured correctly then the SDK should supply all the proper parameters to avoid an error. There is no overhead needed on your part.

Yeah, that is my understanding.  However, there is also something very funky going on within the inner workings of the SDK between youtube and google apis which can generate CORS errors.  It's not just on this one page or one browser, I see these kinds of CORS errors regularly.  Hosting half the IMA SDK on a googleapis domain and the player-half on a youtube domain seems a sure fire way to leave the SDK exposed to CORS issues.


Please take a look at the above screenshots (taken this morning) and let me know your thoughts.

Chris Feldman (IMA SDK Team)

unread,
May 10, 2017, 3:36:25 PM5/10/17
to Interactive Media Ads SDK
Hi,

We actually don't support the Video-JS IMA plugin on this forum. You'll have to reach out to that team directly on their GitHub issue tracker. This support channel is only for native SDK implementation queries.

Regards,
Chris Feldman
IMA SDK Team

DFP User

unread,
May 11, 2017, 1:40:33 AM5/11/17
to Interactive Media Ads SDK
We actually don't support the Video-JS IMA plugin on this forum. You'll have to reach out to that team directly on their GitHub issue tracker. This support channel is only for native SDK implementation queries.

I'm getting a vibe that, in the immortal word of Disney's Elsa from Frozen, I should just "Let it Go".  Nevertheless, I am dumb enough to want to help eradicate the CORS errors for not just me but also others.  I started down this road because the Google AdSense team rejected my video test page because of CORS errors.  After weeks of trying to identify why my IMA-based player was rejected, it's become apparent that the test engineer at Google AdSense was running the Google Doubleclick Publisher Toolbar (DPT) extension.  The Doubleclick Publisher Toolbar interferes with the Origin headers between the Google IMA and Google AdSense.


Ok, so that is one use case resolved.  But as of this morning, I still don't have a perfectly clean console across all browsers when using the Google IMA reference implementations.  Attached is an example of CORS errors in the console when visiting https://googleads.github.io/googleads-ima-html5/advanced/.  This error is with the "IMA HTML5 SDK Advanced Demo" not the "Video-JS IMA" reference implementation.

This screenshot was taken in Safari 10.1.  Clean browser, no extensions, empty cache, no cookies.  It is not reproducible every time, it is not isolated to any one individual machine or any one network, but it ReallyReallyReallyDoesHappen.  Please believe me.  This screenshot has not been photoshopped.


Chris Feldman, would you be able to explain what is happening in the error messages in the screenshot attached, taken this morning?  I presume that this page is supported.




In order to contribute to the community, here is a table of various CORS errors that I have seen with various IMA SDK pages, reference implementations, Google extensions or plugins.  Each error is caused by a different part of the ecosystem, but the messages are misleadingly similar.  The various errors and messages are phrased slightly differently depending on the browser implementation.  The unsuspecting publisher hardly stands a chance.  I do hope this table helps others and could one day contribute to improved documentation or a CORS FAQ for publishers implementing the IMA.


Use case

Typical Error

Possible Solution

Video Suite Inspector (VSI) reference implementation.

Chrome reports...


Redirect from 'https://www.google-analytics.com/r/collect?v=1&_v=j54&a=572720829&t=event&_…2.1494471726&_r=1&cd5=en&cd3=0&cd8=scriptsafe&cd1=Signed%20out&z=184818249' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'https://google-developers.appspot.com' is therefore not allowed access.

Caused by an error on the underlying webpage that hosts the IMA SDK reference player rather than the IMA SDK itself.


Solution: IMA SDK team have reached out to the team who host the Video Suite Inspector page.

Official VideoJS-IMA plugin

Safari reports…


[Error] Unable to post message to https://www.youtube.com. Recipient has origin https://imasdk.googleapis.com.

The official VideoJS-IMA plugin is not supported by this IMA SDK forum.


Solution: Publisher should reach out to the VideoJS-IMA team through the Github Issue Tracker.

Any IMA reference page where the user has the official Doubleclick Publisher Toolbar (DPT) extension installed.

Chrome reports…


XMLHttpRequest cannot load https://googleads.g.doubleclick.net/pagead/id. Redirect from 'https://googleads.g.doubleclick.net/pagead/id' to 'https://googleads.g.doubleclick.net/pagead/id?dpt=1' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.youtube.com' is therefore not allowed access.

The official Google Doubleclick Publisher Toolbar (DPT) hijacks the ad request request, but during the redirect process modifies the origin headers.  Look for dpt=1.


Solution: Disable the official Google Doubleclick Publisher Toolbar extension.


If the Google AdSense team reject your player implementation and point you to https://developers.google.com/interactive-media-ads/docs/sdks/html5/ads#cors, ignore the default response, explain that this advice is not relevant (AdSense IS the ad server), and ask the AdSense team to re-test without the Doubleclick Publisher Toolbar enabled.

Any VAST player pointing to an ad server which does not follow VAST 3.0 best practice for CORS.

Chrome reports…


The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'https://imasdk.googleapis.com' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

This is caused by the VAST 2.x/3.x/4.x ad server not following the CORS guidelines in the VAST 3.0 Specifications or Google's Best Practice for IMA.  (DFP, AdSense, Ad Exchange are all compliant)


Solution: Reach out to your ad partner and raise a bug.  Point them in the direction of the VAST 3.0 specification. This is the one and only case where https://developers.google.com/interactive-media-ads/docs/sdks/html5/ads#cors is relevant.

Official IMA HTML5 Reference Implementation

Safari reports…


[Error] Unable to post message to https://www.youtube.com. Recipient has origin https://imasdk.googleapis.com.

Screenshot attached to this post. Probably the same error as VideoJS-IMA plugin.


Solution: ???


I hope the above table helps clarify the various kind of CORS issues for other publishers.

Meanwhile, Chris, would you be kind enough to take a look at the screenshot in this post and explain where the CORS error is coming from?

Thanks,

A DFP User

Chris Feldman (IMA SDK Team)

unread,
May 11, 2017, 3:04:10 PM5/11/17
to Interactive Media Ads SDK
Hi DFP User,

This is an great list, and an excellent contribution to the community. I do appreciate you taking the time to make this write-up.

About your final question regarding the error in your screenshot, I'm going to have to again direct you to the videojs-ima GitHub Issue Tracker. The URL at the top of the page shows that you're on the Video-JS reference page

Regardless, in an effort to be thorough, I also tested our Advanced Demo on Safari 10.1. The screenshot you shared shows that you're using one of our ad rules sample tags and because I couldn't tell which one, I tested them all a few times, clearing my cache before each test. I was never able to reproduce the error. There isn't any action we can take on our end without being able to replicate the issue. If you continue seeing the error on our page (not videojs-ima), can you share the exact tag that you're using to test, along with detailed steps for how to reproduce the error? 

Regards,
Chris Feldman
IMA SDK Team

DFP User

unread,
May 11, 2017, 4:23:35 PM5/11/17
to Interactive Media Ads SDK
About your final question regarding the error in your screenshot, I'm going to have to again direct you to the videojs-ima GitHub Issue Tracker. The URL at the top of the page shows that you're on the Video-JS reference page

Thanks Chris.  Don't worry, I did not ignore your advice that videojs-ima was not supported.  The screenshot in my last post was taken using the https://googleads.github.io/googleads-ima-html5/advanced/ page (NOT the videojs-ima page, which, as you said, is unsupported on this forum).  I apologize for not making this abundantly clear.  I'm trying very hard to play by the rules of what is and what is not supported.


The screenshot you shared shows that you're using one of our ad rules sample tags and because I couldn't tell which one, I tested them all a few times, clearing my cache before each test.

This is the default tag that I was using on the IMA HTML5 Advanced demo (not the videojs-ima page).



Thanks for testing.  I'll continue to test at my end on various browsers and machines and log any further CORS errors.  It looks like since the 3.168.0 release, things have improved somewhat.

I hope you appreciate where I'm coming from.  From a publishers' point of view, it is frustrating that the VAST Inspector pages, Doubleclick Publisher Toolbar, videojs-ima examples can all create some form of CORS errors without a publisher writing a single line of code or using any non-Google component.  I do realize this forum is focused around the IMA SDK, but these components are all part of an ecosystem which should interoperate without errors in the console.

Chris Feldman (IMA SDK Team)

unread,
May 12, 2017, 2:51:38 PM5/12/17
to Interactive Media Ads SDK
Hi DFP User,

The videojs-ima plugin is supported, just not on this forum. If you reach out on their issue tracker, you will get a response.

I tested a bit more this morning with that tag and I'm still not seeing the console error. If you continue to have issues, and you can isolate the specific circumstances in which the error occurs, please don't hesitate to follow-up with more information. I'll be happy to continue investigating. We absolutely understand your desire to get everything working without errors. 

Regards,
Chris Feldman
IMA SDK Team

Reply all
Reply to author
Forward
0 new messages