Recent updates to Firefox and Chrome prevent pages from mixing http and https content without explicit user permission. This is not specific to cm_ or Clodcast. All media_[providers] must support https. The code that was copied from media_youtube included the necessary code to allow the option in the display settings, but it was commented out when generating the URL.

http://drupalcode.org/project/media_cloudcast.git/blob/refs/heads/7.x-2....

Comments

kreynen’s picture

kreynen commented
Status: Active » Needs review

http://drupalcode.org/project/media_cloudcast.git/commit/6368364

Nia’s picture

Nia commented

Saw what happens if we don't commit the fix on pantheon. The dev site DID NOT appear correctly and the live site DOES appear correctly.

jdcreativity’s picture

jdcreativity commented

Would this also be related to an issue with the Cloudcast Feed not working?

The log message is:

cURL error (6) Could not resolve host: cloudcast.telvue.com; Name or service not known for http://cloudcast.telvue.com/api/mrss/v2/mrss/T01500.xml

The answer is to patch?

kreynen’s picture

kreynen commented

The short answer is no. Long answer...

The https:// issue only presents itself when a page is loaded using https:// tries to include an iframe from a URL that is just http://. That is happening on the user's computer for DNS lookup. In most cases that will be the DNS given to them from their ISP, a public wifi network, or Google's DNS (if they are savvy and want more reliable DNS lookups).

When the Feeds module tries to pull in the RSS from http://cloudcast.telvue.com, it's using the server's DNS.

That error was most likely related to the Network Solution DNS outage yesterday. Without getting into specifics, Telvue posted that on http://engineering.telvue.com/

It's possible the server's upstream DNS has cached the fact that cloudcast.telvue.com didn't exist for several hours yesterday. That outage also impacted RETN and MassAccess.

http://on.wsj.com/19Zf16q

While that was only a few hours vs. what happened during the Anonymous DoS attack on GoDaddy, most groups I talked to because "their website wasn't working" were using Network Solutions for both DNS registration and DNS service. I can't reiterate often enough what a REALLY BAD idea that is! I tried to spell this out in language everyone could understand during the GoDaddy issue...

https://groups.drupal.org/node/253433

Unfortunately most Community Media organizations are still using the same service for DNS registration and service creating a single point of failure with no work around other than just waiting for the service to be restored.

avguy’s picture

avguy commented
Issue summary: View changes
Status: Needs review » Fixed
stefanwray’s picture

stefanwray commented

Great. Thanks for dealing with this.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.