HTTPS (SSL) support for YouTube player.

FYI, two ways that you can set the required variable.

Add this to your settings.php file:

$conf['media_youtube__secure'] = TRUE;

OR

run this drush command:
drush vset media_youtube__secure 1

Seems like there's a bug in this patch. Viewing a page with an embedded video redirects to 'undefined://theurl'. This is likely because 'settings.protocol' is undefined in media_youtube.js. I'm looking into it.

**UPDATE**

my bad-- I didn't roll the patch against the most recent dev version! no problem.

switching status

Any updates on this? I would love the media:youtube to not break my SSL. Any ideas?

I found a fix by going into each of the modules files. Notably the includes and includes/theme files.

I changed every http to https and it worked! Now my site works in SSL with youtube videos. Sweet!

I'm not sure why a new variable is needed for this? Why not automatically get this from global $is_https?

All I know is that youtube supports https so as long as the module uses https in place of http, it won't throw Chrome security warnings because the site and all its assets are secure.

Can someone commit this so this module doesn't throw security warnings to users?

Coming back to Dave's question: should the protocol just be adjusted based on the host page protocol? Or should this become a configuration option in the module settings, e.g.
- Always use https protocol
- Mixed mode: use protocol of page that embeds video

Jens

I honestly can't think of a single reason all communication shouldn't go over https. Youtube now supports it, so why not? I can't think of a good reason. But then again I'm no guru.

If I were an experienced enough developer and on this team, I'd just say make every http -> https in the module like I already have done to get mine working. All videos automatically support it without having to write or rewrite anything fancy.

There's my 2 cents.

My sense is that in most cases you just want to use the page's protocol to draw content from youtube. There may be a use case where an insecure webpage wants to draw secure content from YouTube - maybe some channels are always secure on YouTube??? - but I don't know them. The one thing the module currently does that has to be avoided is to use http for YouTube content on a page being delivered via https.

Again I'm no expert, but I cannot see a single downside to transmitting everything from youtube via https. https youtube feeds won't break a non-https site, however a non-https video feed WILL break an https site and throw security errors. Youtube now supports secure connections so why not use them for everything? All you have to do is put https before the same youtube address on any video. I just can't see any downside because I have been running this module hacked for a couple months now without any negative side effects. I can't see how having secure embedded content inside a non-secure Drupal site would be a bad thing ever. However I can see how the reverse of this is. But if someone wants to write more complex code to see if the site is secure I don't see the problem with that either. All I know is that more security is better, but I have to agree that flexibility is good too.

A new patch which uses global $is_https to determine whether the connection is secure as suggested in #8. Works without any variable or settings.php changes.

Can we not just use protocol-relative URLs? ie, ones that start with // instead of http:// or https:// ? Or, maybe bot because the filter output is cachched by default in media?

I'm with #15, just drop the http/https and let the youtube embed figure it out. The research I did for a patch in another issue made this seem like the safest route.

Regarding #15 and #16: protocol-relative URLs sound like a good solution for the actual embed context on a page (to be viewed by browsers). However, for a context such as email or RSS feed you would still have to include either http or https. There is a related discussion about protocol-relative URLs at http://stackoverflow.com/questions/4303633/preventing-secure-insecure-er... which points to some issues with email and protocol-relative URLs (although this is 2 years old).

In principle I agree with ckopack: there does not seem to be a reason to not always use SSL for YouTube. However, if you want to have a mixed-mode site that does adjust protocol for all content, including external content, then using the $is_https variable to switch dynamically in all contexts seems most flexible.

Thanks for the link, Jelo, good catch. As far as I can see, protocol-relative urls don't have any advantage over checking $is_https.

Is there any reason that a site maintainer would need to specify a protocol different from their site's? If not, we can write this directly into the theme.inc; otherwise we'll need to make a module configuration page which Media: Youtube doesn't have/need yet.

One problem with using $is_https and and embedding absolute http or https links within content is that media's text format output is cached by default. Which means that content will have absolute protocol specific urls embedded within it, based upon what protocol that page was first accessed over. If SSL redirection rules change, or if a page is accessible over both http and https, then the this will cause problems.

In the case of #19 I think the safest thing to do is to always embed with the https link. This won't break in any context such as page display, RSS feed, email and at the same time should work with caching.

Otherwise, in a mixed mode, if a page gets accessed through http first (and hence gets cached) any subsequent visit over https would still serve the cached content, incl. the http embed link, which would then throw warnings in the browser, right? I ran into this problem previously with a module called pathfilter. I used absolute URLs and pathfilter rewrites any internal links like baseurl/node/3 in your page to the correct alias like baseurl/alias. Same problem: it gets cached in the http version and a visitor over https suddenly switches back and forth between http and https. That really leads to the question if there should not be a cache for secured and unsecured nodes so that each node can have 2 cache entries based on protocol.

> That really leads to the question if there should not be a cache for secured and unsecured nodes so that each node can have 2 cache entries based on protocol.
That's an interesting idea, but I think its way outside of the scope of this issue. That would be a problem for Drupal Core to solve.

For now, I suggest we either embed protocol-relative urls, or we just stick to https. I can't really think of a good reason why it would be a problem to have a link as https, other than a miniscule amount or possibly unnecessary overhead initialting the https connection with youtube's servers.

Regarding the problem embedding with protocol-relative urls into emails. are people really going to be embedding youtube videos into emails? Would that even work?

Wouldn't it work similar to what this module does when it detects an mobile apple device that doesn't support flash? I believe it links to the video (which then opens in the YouTube app) with a video thumbnail.

In case of email context, instead of an actual embed, you would need to determine if the email is composed as plain text, mime, html and then for cases such as html include the video thumbnail with a direct link to the video on YouTube. However, I am not sure if media_youtube would do this or if the actual email module (such as print) would need to make this functionality available. With the current setup you can control display of fields for webpage, print, RSS, tokens. I wonder why we do not have email and social? That would allow granular control of what gets displayed in what context. Maybe another core suggestion... I will put it in with the cache suggestion. [edit: I just realized that various view modes have been added in D7, e.g. Email: Plain, Email: HTML, Email: HTML text alternative => in D7 you could exclude a video embed from appearing in the content variable for these contexts]

In any case, to solve this immediate issue: for email context protocol-relative urls would not work as I understand it. Hence, the link would have to be adjusted for that purpose to include the protocol (even if it defaults to https). I would assume that the various modules that provide email capacity would need to all make sure to search and replace protocol-relative urls to add the protocol. For that reason alone (avoiding compatibility issues with other modules) I would vote for using https by default. This would not break any functionality such as emailing content.

After some more research the only downside of https embeds I could find is https adds latency to data transfer. If there's a large list of Youtube iframes and a browser needs to handshake for each one, you're going to add some time onto the page rendering. I think this doesn't matter too much for initial page performance since we have width and height on the embed, and anything in an iframe is in a different context than the parent document so extra time won't affect window.onload.

The usual other arguments against don't apply here: extra server load from encryption is taken care of by Youtube (not our problem), https in a http page throws no warnings, and browser caching isn't an issue anymore.

Is there any situation where a site owner would want to specify http over https?

Hey again all~

I really appreciate the constructive dialogue while everyone tries to tackle this issue. My 2 cents:

Why not make it an option set as https by default that you can turn off in the config if you are worried about performance? That way its not breaking anyone's website (throwing security errors) that serves https, but for the speed junkies that aren't worried about it they could turn https off either in a simple config file or a config page. Please see supporting article:

http://support.google.com/mail/bin/answer.py?hl=en&answer=74765

The consensus I have been seeing across many mainstream websites is that all transactions should take place via https unless of course you don't have the time or resources to deploy a validated certificate. Facebook and twitter even have gone to https as the standard because of the security implications of not doing so.

Great reason not to use standard http: http://codebutler.com/firesheep

For now I hacked the module just by replacing all instances of http with https and it fixed my site and I no longer get security warnings. A huge upside for my users and no real downside for me.

I completely agree with jelo that emailing youtube videos should really be the concern of those modules.

Why not make it an option set as https by default that you can turn off in the config if you are worried about performance?

Right now there is no site-wide configuration for Media: Youtube, just the field formatter options in Manage Field Display. The best solution would be to solve this in code (using a conditional, or just picking a single protocol/https) and not introduce any additional complexity into the module. But if it's a situation where a bunch of people are going to need to hack/patch the module to bring it back to http, a global config page is a better route.

You da man!

I think you are on the money. Single simplified protocol seems logical.

Maybe to summarize. We seem to have agreement on the fact that protocol-relative URLs are not a solution because of potential incompatibilities (e.g. with email).

That leaves these options:
- switch dynamically based on hosting site protocol
- set a default without configuration option (would need to be https)
- allow user configuration

Our initial goal was to fix the security warnings a user sees when embedding insecure content in a SSL setup. All of these options would work. However, we now discuss adverse effects on module users who do not want to use SSL and might mind the minimal latency it might create. The best of all worlds seems to me to automatically switch protocols based on the is_https variable.

Advantages:
- fixes the insecure content warnings
- does not create latency if you are not using SSL => nobody needs to hack this module back
- does not require complex additions to the module (no configuration screen etc.)

Problem: caching => is this still an issue or not? After I posted about my caching issues I remembered that I recently used a cache clear module (for individual nodes) where I discovered that in fact now each node might have a cache for SSL and non-SSL already. Can somebody with a better understanding of Drupal caching maybe clarify if we would run into issues with dynamic protocol switching and cache?

When I looked into caching, I found this issue http://drupal.org/node/1377840

Interesting that a suggestion is to switch everything to protocol-relative in D8... As cache still seems to be an issue, would it be easy to add a checkbox to admin/settings/media_youtube to configure if http or https should be used? The box could be under "Show related videos" and be titled "Use SSL embeds" or something like that... For me ssl by default would be fine and I do not care about the minimal latency, but I do see the point that not every user of this module might see it this way...

Media: Youtube settings are a file formatter right now, not a global settings page. I don't think we'd want to have users set http/s for every view mode or field display they set up.

Protocol relative URLs would be great if caching problems didn't exist, but since there are open issues trying to address that I think it's safer to go with https as default. If anyone notices and is bothered enough to file an issue against https-as-default, we can move the choice (some combo of relative, force http, force https, or use $is_https) to a global config.

Added the two necessary "s"es in this patch (wooh, hard work).

By the way, M:YT has always set https as default when outputting the object tag in media_youtube.theme.inc, but then replaced it with an http iframe in media_youtube.js. Code fragmentation = another reason that the replace-object-with-iframe-js is not the greatest thing in the world.

I'm marking this as fixed, because this appears to have already been committed in the latest 7.x-2.x code. Does it need a backport to 7.x-1.x?

Ah yeah. The "use iframe with no js" patch implemented https as default, based on the discussion here. That patch needs a 1.x backport, any help would be greatly appreciated.

The protocol handling is going to change soon, based on this issue: #1768362: Add http/s/relative protocol options to fix protocol handling for js API and email/rss; choose https or relative as default. Feedback welcome over there.

From commit d0377b3 I need that validId use "https".

Patch attached.