allow-access problem on imasdk

[Onur Coşkuner]

Hi,

We are getting an allow-access error on our test page,

Test Page : https://onedio.com/player/58dccb38d6b269ab11f8db28/58dccb38d6b269ab11f8db27?i=v&vast=ok

Error : XMLHttpRequest cannot load https://bs.serving-sys.com/Serving?cn=display&c=23&pl=VAST&pli=20896934&PluID=0&pos=2874&ord=[timestamp]&cim=1. 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.

We could not found the main reason of this problem. 

Do you have any suggestion?

Thanks,

Onur.

[Oren Melamed]

See here: https://developers.google.com/interactive-media-ads/docs/sdks/html5/ads#cors

[Chris Feldman (IMA SDK Team)]

Hello, 

Thank you for providing the helpful link, Oren.

Onur, I did not see this issue while testing with your page. However, based on the description this is not an SDK issue. It looks like the problem is with your CORS header. In this case, the ad server is setting the " * " wildcard in the "Access-Control-Allow-Origin" header and also setting the credentials mode to "include" which is not allowed by the standard. 

Let me know if you have any other questions.

Thanks,

Chris Feldman

IMA SDK Team

[Onur Coşkuner]

Hi Chris,

Yes the exact problem is CORS headers. However this protocol mis-match is between https://imasdk.googleapis.com and https%3A%2F%2Fbs.serving-sys.com%2FServing%3Fcn%3Ddisplay%26c%3D23%26pl%3DVAST%26pli%3D20896934%26PluID%3D0%26pos%3D2874%26ord%3D%5Btimestamp%5D%26cim%3D1&sa=D&sntz=1&usg=AFQjCNFO469ULcdTN_yfAVfaTYHN2yEtUQ 

Sizmek server vast url served with header : "Access-Control-Allow-Origin" "*" wildcard. We could not modify this headers. Is there any settings under IMA library to allow this header options.

Thanks,

Onur.

[Chris Feldman (IMA SDK Team)]

Hi Onur,

You'll have to reach out to your ad provider to resolve this issue as there is no way to remedy this via our SDK.

From our documentation:

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.

Regards,

Chris Feldman

IMA SDK Team

[DFP User]

Hi Onur,

You can use cURL to determine whether your ad provider's server returns the correct CORS headers in accordance with the VAST 3.0 Specification.

In your example tag, MediaMind's ad server (serving-sys.com) does not set the CORS headers according to the VAST 3.0 Specification.  You should reach out to MediaMind and raise a bug, quoting section 2.1.5.2 Cross Origin Resource Sharing (CORS) for JavaScript of the VAST 3.0 Specification.  (BTW, good luck with that!).

$ curl --head --header "origin: https://imasdk.googleapis.com" --request GET 'https://bs.serving-sys.com/Serving?cn=display&c=23&pl=VAST&pli=20896934&PluID=0&pos=2874&ord=123123123&cim=1'

 

HTTP/1.1 200 

Cache-Control: no-cache, no-store

Pragma: no-cache

Content-Type: text/xml; charset=UTF-8

Expires: Sun, 05-Jun-2005 22:00:00 GMT

Server: Microsoft-IIS/7.5

Set-Cookie: S_2874=7510697228925946678; expires=Mon, 08-May-2017 06:38:00 GMT

Set-Cookie: CISI_2874=ei=43588556_asi=0_di=0_il=0_sid=7510697228925946678; expires=Sat, 06-May-2017 14:53:00 GMT

Set-Cookie: u2=9cbf64ca-30ce-4ab5-95c5-0ecd86ffed274ec070; expires=Fri, 04-Aug-2017 14:38:00 GMT; domain=.serving-sys.com; path=/

Access-Control-Allow-Origin: *

X-Powered-By: ASP.NET

P3P: CP="NOI DEVa OUR BUS UNI"

Date: Sat, 06 May 2017 18:38:56 GMT

Content-Length: 1831

According to the VAST 3.0 specification, "the value of Access-Control-Allow-Origin should be the value of the Origin header sent with the ad request".  So in the above case, MediaMind should have returned "Access-Control-Allow-Origin: https://imasdk.googleapis.com".

Here is an example of the Google DFP Ad Server doing it correctly, in accordance with the VAST 3.0 specification.

$ curl --head --header "origin: https://imasdk.googleapis.com" --request GET 'https://pubads.g.doubleclick.net/gampad/ads?sz=640x480&iu=/124319096/external/single_ad_samples&ciu_szs=300x250&impl=s&gdfp_req=1&env=vp&output=vast&unviewed_position_start=1&cust_params=deployment%3Ddevsite%26sample_ct%3Dskippablelinear&correlator=1234567'

 

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: https://imasdk.googleapis.com

Access-Control-Allow-Credentials: true

Google-LineItem-Id: 697200496,697200496

Google-Creative-Id: 57860459056,57857370976

Date: Sat, 06 May 2017 18:46:46 GMT

Pragma: no-cache

Expires: Fri, 01 Jan 1990 00:00:00 GMT

Cache-Control: no-cache, must-revalidate

Content-Type: text/xml; charset=UTF-8

X-Content-Type-Options: nosniff

Server: cafe

X-XSS-Protection: 1; mode=block

Set-Cookie: test_cookie=CheckForPermission; expires=Sat, 06-May-2017 19:01:46 GMT; path=/; domain=.doubleclick.net

Alt-Svc: quic=":443"; ma=2592000; v="37,36,35"

Accept-Ranges: none

Vary: Accept-Encoding

Transfer-Encoding: chunked

And now using an entirely arbitrary value in the header, say for example "foobar".  This is *exactly* the behavior described in the VAST 3.0 Specification (Nice job, Google DFP!)

$ curl --head --header "origin: foobar" --request GET 'https://pubads.g.doubleclick.net/gampad/ads?sz=640x480&iu=/124319096/external/single_ad_samples&ciu_szs=300x250&impl=s&gdfp_req=1&env=vp&output=vast&unviewed_position_start=1&cust_params=deployment%3Ddevsite%26sample_ct%3Dskippablelinear&correlator=7654321'

 

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

Google-LineItem-Id: 697200496,697200496

Google-Creative-Id: 57860459056,57857370976

Date: Sat, 06 May 2017 18:50:45 GMT

Pragma: no-cache

Expires: Fri, 01 Jan 1990 00:00:00 GMT

Cache-Control: no-cache, must-revalidate

Content-Type: text/xml; charset=UTF-8

X-Content-Type-Options: nosniff

Server: cafe

X-XSS-Protection: 1; mode=block

Set-Cookie: test_cookie=CheckForPermission; expires=Sat, 06-May-2017 19:05:45 GMT; path=/; domain=.doubleclick.net

Alt-Svc: quic=":443"; ma=2592000; v="37,36,35"

Accept-Ranges: none

Vary: Accept-Encoding

Transfer-Encoding: chunked

So why should we care if MediaMind returns an incorrect response?

• Modern browsers (Safari, Chrome Edge) have started become more strict and to spit an error in the JavaScript Console if the Ad Server returns Access-Control-Allow-Origin: * and Allow-Credentials: true.  Depending on your flavor of browser, you will find a message similar to "A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true." in your console.
  
• If you are a publisher who uses the IMA Native SDK for Android/iOS, you will find "chromium: [INFO:CONSOLE(0)] "XMLHttpRequest cannot load https://[ADSERVER]/vast.xml. 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 'http://imasdk.googleapis.com' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.", source: https://imasdk.googleapis.com/native/sdkloader/native_sdk_v3.html?sdk_version=a.3.2.1&hl=en&wvr=2&app=com.example.myapp (0)".  The SDK will retry, and the second request will work without issue.  A non-compliant ad server see two requests from your app, but you will have only generated one impression.  Apart from the misleading fill rate / use-rate, you have wasted several hundred milliseconds of your audience's valuable time.

MediaMind are not alone in being non-compliant.  I only reference them because of the example tag shared by the original poster.  There are many ad servers/networks/exchanges who do not follow the VAST 3.0 specification and continue to return a wildcard.

As a web/app publisher community, please put pressure on your ad providers (ad servers, networks, exchanges) to set their CORS headers in accordance with the VAST 3.0 Specification.  This is the only thing that web/app publishers can do rid ourselves of this misleading noise in the JavaScript Console.

Ideally, the Google Video Suite Inspector would include an origin validation to flag if an ad server has returned the correct Access-Control-Allow-Origin.  This would be far more effective in dragging the ad server, network, exchange community towards VAST 3.0 compliance than a few lone publisher voices.

As a final note, when it comes to CORS errors in your browser logs, the Google IMA HTML5 SDK has it's own CORS issue, totally unrelated to the response received from an ad server.  Although both issues create very similar looking error messages in your console logs, one is caused by the response from the ad server (as per this thread) and the other is caused by the Google IMA SDK, independent of the ad server.  Since the error messages look similar, it is very easy to confuse the two issues.  Be warned, there are many cases of misleading advice regarding CORS on this forum.

[Onur Coşkuner]

Hi Chris,

That problem solved by the sizmek/reklam provider. Thanks for your response.

But this time we get an error like below,

When IMA SDK loads the preroll ad its blocked by the google chrome browser in android mobile devices. ( by the way, this videos are not autoplay, all videos start with user play action).

Example url link : http://staging.dev.oned.io:6593/player/58dccb38d6b269ab11f8db28/58dccb38d6b269ab11f8db27?i=v&vast=ok

Do you have any suggestion about this problem?

Thanks.

On Thursday, May 4, 2017 at 6:29:49 PM UTC+3, Onur Coşkuner wrote:

[Chris Feldman (IMA SDK Team)]

Hi Onur,

It looks like you're using the videojs-ima plugin. This forum only supports native IMA SDK implementations. For this issue, you'll have to reach out for support on the plugin's GitHub Issue Tracker.

Regards,

Chris Feldman
IMA SDK Team