Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

re: difficult time with JWplayer and Ads implimentation

http://mp4stream.com/preroll/videe/
This is one of many demos I have setup for various Ad Networks. Almost all have the same result.

Part One
A lot of the Ad Networks I've demoed all have the same issue that looks something like this. I'm talking at least 10 partners I've tested have. Below is an example of one.

XMLHttpRequest cannot load http://vast.videe.tv/vast-proxy/?VPAID=1&aid=12988&sid=0&channel_id=0&conte…player_width=657&player_height=370&vid_duration=1440&cb=685997865628451100. A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://mp4stream.com' is therefore not allowed access.

These failures create a huge increase load time and affects the entire player / user experience as a whole.

One Ad Network today indicated that I may be passing cookies to them and that is why the above is failing. But I have a hard time believing that based on my development / server experience. As far as I'm aware every single player JWplayer or otherwise would use cookies of some kind.

So the question I have is why do hundreds of these simply fail?

6 Community Answers

Up Down

Todd

JW Player Support Agent  
-1 rated :

The error you are seeing is related to CORS. Essentially these domains need to give you permission to load their ad tags, so there is nothing you can do directly to resolve this. My suggestion is to reach out to your contact at each company and request that they whitelist your domain.

Our player saves your volume and video quality selection (like if you choose 720p or 1080p) in a browser cookie, but we do not pass cookies to ad networks.

Please see http://support.jwplayer.com/customer/portal/articles/1403679-crossdomain-file-loading for more details.

Try testing your player with the following ad tag. I believe they have their CORS set to allow access to everyone:

http://www.adotube.com/php/services/player/OMLService.php?avpid=oRYYzvQ&platform_version=vast20&ad_type=linear&groupbypass=1&HTTP_REFERER=http://www.longtailvideo.com&video_identifier=longtailvideo.com,test

Up Down

grant.mucha

User  
0 rated :

Dear Todd,

As I mentioned above, I work with like 10+ Ad Networks, mostly in USA and Europe. Large Ad Networks. So your telling me that, huge Ad Networks that run an insane number of impressions monthly, basically have their setup wrong. Why wouldn't they white list my domain when setting me up as a publisher. Would that not be a critical part of the setup process?

My theory would be:
I find it extremely odd that Ad Networks would provide tags that would not work. This kind of hinders success.

I'm setting up a demo page based on the tag you provided above. But as it stands now, the JWplayer premium Ads package is turning out to be useless. The entire reason I purchased JWplayer was to utilize the waterfall option for preroll. And all that causes is insane delays in loading the actual stream (due to so many failures.)

FURTHER INFORMATION
Todd, "I believe they have their CORS set to allow access to everyone."

Everyone has CORS set to allow everyone. The problem is not that they allow everyone its the allow credentials flag.

A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://mp4stream.com' is therefore not allowed access.

Access-Control-Allow-Origin "*"
Access-Control-Allow-Credentials "true"

Allow Credentials cannot be true when allowing everyone access. The only way to use "Access-Control-Allow-Credentials" is to specify a domain name in "Access-Control-Allow-Origin".

NOTICE:
This tag in no way resembles tags provided to me by large Ad Networks. This tag in fact looks rather cooked.
http://www.adotube.com/php/services/player/OMLService.php?avpid=oRYYzvQ&platform_version=vast20&ad_type=linear&groupbypass=1&HTTP_REFERER=http://www.longtailvideo.com&video_identifier=longtailvideo.com,test

I did a quick CURL test of this to check for CORS of course.

curl -I http://www.adotube.com/php/services/player/OMLService.php?avpid=oRYYzvQ&platform_version=vast20&ad_type=linear&groupbypass=1&HTTP_REFERER=http://www.longtailvideo.com&video_identifier=longtailvideo.com,test

Returns:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
= THIS SHOULD BE IMPOSSIBLE BASED ON THE RULES OF CORS
= If Allow-Credentials is set to TRUE Allow-Origin cannot be a wildcard
Yet somehow, your tag still returns a preroll advertisement. So your tag is operating outside the laws of the internet?

MINE: NONE OF THESE WORK AND ALL HAVE THE SAME CORS VALUES AS YOUR TAG
http://vast.videe.tv/vast-proxy/?VPAID=1&aid=12988&sid=0&channel_id=0&content_page_url=__page-url__&player_width=__player-width__&player_height=__player-height__&vid_duration=1440&cb=__random-number__

http://ad4.liverail.com/?LR_PUBLISHER_ID=151439&LR_SCHEMA=vast2-vpaid&LR_VERTICAL=preroll&LR_URL=__page-url__&LR_AUTOPLAY=0&LR_CONTENT=6&LR_MUTED=0&LR_VIDEO_ID=__item-mediaid__&LR_TITLE=__item-title__

http://video.bnmla.com/video?vzid=4422&vast=1&vWidth=__player-width__&vHeight=__player-height__&ohname=__page-url__&cb=__random-number__

http://ad4.liverail.com/?LR_PUBLISHER_ID=151380&LR_SCHEMA=vast2-vpaid&LR_URL=__page-url__&LR_AUTOPLAY=0

So in the end all of the above tags return exactly the same CORS information as your "test" tag.

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *

Yet when I try your cooked test tag I get an add fill.

And when I try any of my tags above I get:

XMLHttpRequest cannot load http://vast.videe.tv/vast-proxy/?VPAID=1&aid=12988&sid=0&channel_id=0&conte…player_width=657&player_height=370&vid_duration=1440&cb=239739479264244450. A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'http://mp4stream.com' is therefore not allowed access.

They have the SAME setup as ADOtube, yet my request requests fail due to a known rule that if the credentials flag = true, the Allow Origin cannot be a wildcard.

http://mp4stream.com/preroll/jwplayer/ - your cooked tag

CORS response from servers match ADOtube, yet fail because credentials flag is true and when set to true it does not allow an Allow Origin wildcard.
http://mp4stream.com/preroll/engagebdr/
http://mp4stream.com/preroll/videe/


So what I would like to know, is how you bend the laws of the internet and somehow manage defeat the rules. When requesting the ADOtube tag "Allow Origin" is set to a wildcard and "Access Credentials" is set to true. Based on the rules of CORS this should fail, exactly like all of my requests.

I would very much like someone, with a little more experience reach out to me because right now I find JWplayer pretty much useless. And blaming it on Ad Networks that are filling billions of impressions really isn't going to help you maintain my business or likely others. On top of that sending a cooked tag that works when it should clearly fail based on the response from the server. Yet miraculously your tag defies the rules of CORS and still returns a preroll impression.

Up Down

Todd

JW Player Support Agent  
0 rated :

Ad tags directly from the ad networks do not surprise me, but I share your frustration. It would be nice if ad tags gave better insight into why an ad tag does not return a valid ad. Are the ad networks giving any explanation as to what the error might be?

Now that I think about it some more, HTML5 requires CORS. VPAID ads use Flash, therefore they do not use CORS at all, they rely on crossdomain.xml instead. If an ad network served 100% VPAID Flash ads, it is quite possible that they don’t have CORS set on their side at all.

Have you tried your ad tags in our Ads Tester at http://demo.jwplayer.com/ad-tester/ ? How about Google’s Flash ad tester at https://developers.google.com/interactive-media-ads/docs/sdks/flash/vastinspector ?

And that’s not a “cooked” ad tag. We got that one directly from them. Here’s a LiveRail sample ad tag as well:

http://ad4.liverail.com/?LR_PUBLISHER_ID=147157&LR_SCHEMA=vast2-vpaid

Up Down

grant.mucha

User  
0 rated :

Some of the above Ad Networks are now telling me they do not support JWplayer. So essentially I have a million plus impressions that are non monetizable with JWplayer.

Almost ALL Ad Networks serve flash based advertising, every one of them has told me flat out they have higher fill rate and more campaigns. Not a lot of advertisers have migrated to HTML yet.

Perhaps you did not read what I meant by cooked.

Correct me if I'm wrong here:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *

This should always fail, yet with ADO it does not. That is what I mean by cooked tag. When I request the ADO tag using mp4stream.com this should never work. It should always return, "A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true."

How can I try my tags in a random domain tests? Every single Ad Network that has issued tags has thoroughly vetted my website and domain before even issuing tags. I am under the impression the tags will only work with my website.

I have however provided numerous demos using my domain for review of the situation.

I really do not know what else to do and I am literally at my wits end here. I simply cannot get JWplayer to work with the tags provided by industry Ad Networks.

-G

Up Down

Todd

JW Player Support Agent  
0 rated :

I know we have an ongoing support case via e-mail as well, but I wanted to update this community forum in case anyone else comes across it.

Our player should work with any ad server, ad network, or exchange. Please send us any ad tags that are not working in our Ads Tester. You can certainly ask the ad networks to contact us directly at support@jwplayer.com so our engineers can investigate further.

Up Down

klebs

User  
0 rated :

We continue to get "A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true"errors with several ad networks when we use JW. Looks kike the JW player is sending a credentials = true flag all the time, even if the adnetworks do not require this and then conflicts with ad networks wildcard settings.

I believe JW introduced this flag after some users asked for it, see: https://support.jwplayer.com/customer/portal/questions/6242481-withcredentials-with-vast-client , in this thread you see an answer from Ethan Feldman,JW Player Support Agent: "We will have this fixed for 6.9."

Also in an JW email support case with got this answer from JW support tech Alex when we asked to be able to remove the jw player flag setting with a config option: "The version of JW Player that you are using is the only one available and we will not be changing the credentials flag."

The credentials JW player flag now even seems to break our implementation of google video ads:

>> XMLHttpRequest cannot load
>> https://googleads.g.doubleclick.net/...
>> No 'Access-Control-Allow-Origin' header is present on the requested resource.
>> Origin 'http://...' is therefore not allowed access.
>> The response had HTTP status code 400.

the corrosponding vast tag play fine in google ad tester, but causes an: "There was an ad error." message in the JW own ad tester. (see our ongoing email support case)

I find it puzzling that JW keeps saing that the major adworks are doing something wrong setting the "*" access wildcard and that they should do their business having whitelists! This is not how these networks work, they can not whitelist everytime we add a new domain.
if jw is always sending a credentials=true flag we can not use it on many high traffic websites (and we keep payning JW for a solution that is not working).

Ralf

This question has received the maximum number of answers.