The problem:
You spend countless hours preparing video content for your WordPress multi-site installation. Everything is just right and you successfully QA your pages in Internet Explorer, Firefox and Safari. You deploy to production and sleep well at night knowing all is well. Then Adobe releases a âsecurity fixâ for their flash player and you start receiving notices from your customers, who pay to access your content, that your videos have stopped working in their Firefox or Safari browsers. Now you go into firefighting mode until the problems are eliminated.
Background and Impact
Adobe Flash has long been the beast weâve been forced to live with. Perhaps Steve Jobs was right for not supporting flash content in IOS. This site, VictorFont.com, is just one of six domains I own and operate on my Hostek hosted server. The primary site is http://www.fontlife.com/. FontLife.com is the first domain I purchased in the 90s. It started out as a static family website built in html, migrated to .asp, then released as a third generation .NET application. I moved it to WordPress at the beginning of 2010 after conducting an experiment in blogging on WordPress.com. Now I have 5 additional subdirectory sites setup in the same instance of WordPress all of which play video content.
The problem began with a recent update to the Adobe Flash player. You might not realize this, but there are two versions of the flash player, an active-x control for Internet Explorer and a plugin for all other browsers. For displaying my videos, I use a licensed version of the JW Player from Long Tail Video along with the JW Player for WordPress plugin. Until this recent update to the flash player, JW Player has been running great on my site. After the update it continued to run great in IE, but in Firefox and Safari it wouldnât even load the skin never mind play videos. I searched the internet like mad trying to find a solution. All I found is numerous posts from other people experiencing the same problem. There is only one solution I discovered that was offered on a few sites.
For anyone experiencing this problem, the financial impact risk could be enormous. Itâs the job of any business to keep their customers happy. If your customers canât view the content they are paying for, they wonât remain customers for very long. (Thank you Adobe!)
The Solution
Out of desperation, I tried the suggested solution and voila' it worked! What is it? Itâs creating a cross domain policy file and installing it in my siteâs root directory. A support page on the Long Tail Video site says:
The Adobe Flash Player contains a crossdomain security mechanism, similar to JavaScriptâs Cross-Site Scripting restrictions. Flashâs security model denies certain operations on files that are loaded from a different domain than the player.swf. Roughly speaking, three basic operations are denied:
- Loading of XML files (such as playlists and captions).
- Loading of SWF files (such as skins).
- Accessing raw data of media files (such as ID3 tags or sound wave data).
Generally, file loads (XML or SWF) will fail if thereâs no crossdomain access. Attempts to access or manipulate data (ID3, waveforms, bitmaps) will abort.
This certainly explains whatâs happening. The player.swf file is being served up from FontLife.com. The content and skin (xml file) is being served up from VictorFont.com. When I test from FontLife.com, I experience no problems. When I test from VictorFont.com, black screen only, no skin, and no video. The problem is clearly cross domain access.
The issue that truly muddies the water is the fact that everything still works in IE regardless of the domain from which Iâm testing. I suspect the active-x control is not securing cross domain access properly, where the flash plugin in Firefox and Safari is correctly preventing cross domain access as Adobe intends. Whatever the case, adding the cross domain policy file instantly fixed the problem. Iâll get a good nightâs sleep tonight.
For more details about this issue, visit Adobe Cross Domain Policy File Specification.
