Versions of our web player prior to v3.2 do not natively support HTTPS which means that if you attempt to serve it from an SSL-secured server, you'll find that the browser will block certain parts of functionality and certain objects. This is because a secure page may not contain insecure elements. For safety, those elements aren't downloaded.
Most audio streams are insecure too. Testing has shown that some browsers are forgiving and will allow insecure streams to be served into a secure web page but others will block, as per the above.
Modifying the web player (the quickest way)
We've updated our web player generator to generate v3.2 players. As well as HTTPS support, you can benefit from updates to the ad libraries, browser support and general codebase improvements. It's not a mandatory update - but we strongly recommend it.Login to the Station Control Panel, and click the Generate Web Player link next to the appropriate station.
Modifying old web players (by hand)
These are the steps you need to take if you wish to modify the web player to support HTTPS. Please note the concepts are quite complicated and will require a senior web developer to assist. That said, we hope we've made the steps clear.
First, you need to determine whether you are using a version of the web player from the generator tool within the Station Control Panel. Or alternatively we may have given you direct code access.
If you generated a web player using the control panel tool
In a text editor, open the documents: index.html and js/radioplayer.min.js
If you've been given direct access to the code from our repositories
Next - find and replace
To make this process quicker, we suggest you use a text editor that allows you to find and replace across all opened files. Most professional development tools will do this. Please note there will be multiple instances of each URL that will need to be replaced.
Note that we have intentionally removed the protocol definition (the http: bit) from the URL. This has the effect of adopting the protocol which was used to serve the index.html file, as the protocol for these requests. This is known as a protocol-relative URL. It's not a widely known technique but has been around since RFC 1808. Interested in learning more? Click here.
If you're using AdsWizz, it's possible under the current configuration that AdsWizz may be blocked. To reduce the risk of this, you can make the following changes
If you have the player code from our repository, open js/adswizz.js and locate line 1230.
var url = 'http://' + radioplayer.adswizz.adswizzDomain + '.adswizz.com/www/delivery/afr.php?' + zoneId + '&playerid=' + radioplayer.adswizz.playerId + '&context=' + id + '&' + cacheBuster;
Change this to:
var url = '//' + radioplayer.adswizz.adswizzDomain + '.adswizz.com/www/delivery/afr.php?' + zoneId + '&playerid=' + radioplayer.adswizz.playerId + '&context=' + id + '&' + cacheBuster;
If you have a player generated by our tool, open js/radioplayer.min.js and search for
As mentioned at the start of this article, most audio streams are served over HTTP although many streaming companies are now offering secure streams on request. Our initial testing showed that some browsers did allow an insecure stream on a secure page but the support is quite mixed. Users with Flash are least affected because Flash is quite forgiving. To ensure non-Flash listeners aren't affected by a blocked stream, it's worth doing the upgrade to push your streams over to HTTPS.