I would like to be able to use video filter for youtube videos on a site using SSL and not get the mixed content warning.

From all the searching I have done, i found this article,
http://hype-free.blogspot.com/2007/01/including-mixed-ssl-and-non-ssl-co...

It suggests using mod_proxy but I am wondering what the mod_proxy would need to be set to for youtube and if the video_filter module will also require modification.

Any help would be appreciated. Thanks,

Izzy

Comments

I guess some modifications would be nessecary. It says at the bottom of the article you linked to that if you point the player to a local source, it would solve the issues. That would mean that you edit video_filter.codecs.inc to fetch each player (usually .swf) from a local soource instead, and point mod_proxy there. I have no idea if this works though, so if you solve it, please do a write-up so others can benefit!

Interesting, tracking.

Since I was only using Youtube videos my hack was to modify the http in the youtube source address to https in the video_filter_youtube function in video_filter.codecs.inc.

*Note this only works where the content site has a ssl version available and has ssl overhead presumably for each video being linked to.

Status:Active» Closed (won't fix)

I'm gonna close this, since this isn't something that will end up in the module. Great that you got it working though!

#4: Why would you not support SSL sites?

Because it adds overhead, and possibly other issues. If someone gets it rolling on a SSL site, I'd be happy to look at patches though.

Version:6.x-2.7» 7.x-3.0

I had this issue come up as well and although it does seem like not all sites have to deal with this, more and more sites are going all SSL. Given that, it was fairly simple to just rewrite the http in the theme function in our custom theme. But it would be much easier for most as an option in the settings! :)

Status:Closed (won't fix)» Postponed (maintainer needs more info)

As I've stated, I'd be happy to look at a patch that adds settings for this. Also, if anyone can add a sub page here http://drupal.org/node/402796 to explain how this is done in the meantime, that'd be great.

Added book page for the simple theme solution: http://drupal.org/node/1443168

Wouldn't the use of schema-less URLs (starting with //) be simpler than having to switch between http and https? particularly for YouTube

I second the use of schema-less URLs (see #10). I've hacked the generated code for YouTube and Flickr videos/slideshows to use a schema-less URL and that has worked great for me.

Hi,

I looked at the following solution from post #9 (http://drupal.org/node/1443168) and tried to copy the code into my template files of my custom theme.

For starters I could not locate a " template.php" by that exact name in my /sites/all/themes/mytheme/template folder. The files I found there are named like this:

-rw-r----- 1 root www-data  4109 2011-08-18 11:08 comment.tpl.php
-rw-r----- 1 root www-data  2085 2011-08-18 11:08 comment-wrapper.tpl.php
-rw-r----- 1 root www-data  2632 2011-08-18 11:08 maintenance-page.tpl.php
-rw-r----- 1 root www-data  5491 2012-08-14 16:07 node.tpl.php
-rw-r----- 1 root www-data 10452 2011-08-18 11:08 page.tpl.php

I asumed that the code from the above link goes into the "node.tpl.php" file, so I inserted it and suddenly my whole theme was gone. Short story: It did not work.

Am I trying the right thing with the wrong file? I would be really happy if you could provide a little more information as to where exactly I have to insert the code listed on the book page.

Best wishes,
Paul

#12 (paul_constantine)
If it doesn't already exist, create a new file named 'template.php' in sites/all/themes/mytheme. Make sure the file starts with <?php and paste in mshaver's code after that.

Hi pjcdawkins,

thank your for your input. Did what you said and made a new file "template.php" that starts with a < ? php and ends with a ? > (sorry for the spaces, this editor was showing code) in between there is the pasted code from the book page.

  • I changed the owner and the permissions like the other files: root:www-data, 640.
  • Put it in "/var/www/mydomain/htdocs/sites/all/themes/mytheme/", refreshed the page and still I have a mixed warning (padlock with a little triangle).
  • Put a copy in "/var/www/mydomain/htdocs/sites/all/themes/mytheme/templates/", refreshed the page and still I have a mixed warning (padlock with a little triangle).
  • Restarted the webserver, still noch change.
  • After that I maually changed the links in all the videoplayers from http to https, still no change.

The only pages I get the mixed warning are the pages with the video filter. All other pages display a green padlock.

Do I need to reference that template from somwhere?

Best wishes,
Paul

Update: puting the template.php in the bartik theme produces the following fatal error:

PHP Fatal error: Cannot redeclare CUSTOMTHEME_video_filter_flash() (previously declared in /var/www/www.mydomain.com/htdocs/sites/all/themes/bartik/template.php:6) in /var/www/www.mydomain.com/htdocs/sites/all/themes/mytheme/template.php on line 51, referer: https://mydomain.com/forum/43

#14 (paul_constantine)

  • Files only containing PHP should begin with <?php, but they should not end with ?>. This is a Drupal coding standard, and generally good advice anyway.
  • The file should definitely be at "/var/www/mydomain/htdocs/sites/all/themes/mytheme/template.php".
  • No need to restart the webserver.
  • Change CUSTOMTHEME at the beginning of the pasted code to the name of your theme.
  • Clear caches by going to admin/config/development/performance in your Drupal site and click on "Clear all caches".

Sorry pjcdawkins,

no success yet - did everything the way you wrote. Still not secure :-(

My fatal error earlier on produced an interesting side effect: my custom theme color is back to the standard bartik blue and no amount of changing, de-installing and reinstalling will convince my drupal to change back to my custom color or any other color for that matter. Seems that the color module is broken now.

Another problem, another night.

Best wishes,
Paul

P.S. My site uses a combination of User Realationships and content access to achieve something like facebook. Maybe that's srewing up the fix.

Presumably you restored the old version of the node.tpl.php file that you edited in #12...? Code doesn't just break randomly (honest).

Hi pjcdawkins,

thought about possible reasons why the fix on the bookpage (http://drupal.org/node/1443168) did not work on my site. I use plaintext with wysiwyg editors for my users to post their videolinks and their articles:

  • IMCE Wysiwyg API bridge
  • Wysiwyg
  • CKEditor

Could it be, that the above mentioned fix does not work due to these modules?
Just taking wild stabs in the dark here :-)

By the way, my messing around with the template.php really messed up my system for good. I have some errors that don't even go away after a complete drupal update and a re-installation of the bartik theme (http://drupal.org/node/1731382). I've no idea how I managed that, since I made *.bak files of erverything I changed and restored them in SSH when things went wild.

Best wishes,
Paul

Okay, I feel like a complete ass now.

After going over every aspect of my website I found out that I am not only using the video filter (which is used in the CKEditor) but also the video embed field which is used in a videolink node.

Guess what, the videos that were disturbing my SSL certificate were all made with the video embed field. After updating to version 2.0 beta 5 all the problems went away.

Sincere apologies for wasting everyones time here. Anyway, now both my videolink modules are SSL safe.

Best wishes,
Paul

Title:Using Video_Filter on SSL siteIncompatible with HTTPS sites
Version:7.x-3.0» 7.x-3.1
Category:support» bug
Status:Postponed (maintainer needs more info)» Needs review
StatusFileSize
new2.46 KB

Bumping up to latest stable version, and opening again as this is still unresolved. Also renaming and turning into a bug as SSL support is a given for Drupal modules.

A theme level fix, such as #9, is not a good or permanent solution. A schema-less approach to URLs, like #10 suggests, is tried and true and used in all sorts of other Drupal modules, let alone outside the Drupal community.

Proposed Solution

For video services that support SSL, such as YouTube, use schema-less URLs. For services that this is unknown, use http.

And to get us started, here is a patch to 7.x-3.1 that turns all Vimeo and YouTube links schema agnostic.

StatusFileSize
new2.46 KB

Re-uploading due to missing forward slash.

Priority:Normal» Major
Status:Needs review» Reviewed & tested by the community

The module is pretty much useless for https sites without this patch, and it is also incompatible to drupal!

So it shouldn't take a major roll if this is implemented or not.

There should be a bug fix release!

@pianomansam, Thanks. I used changes similar to the patch in #21 for 6.x-3.1 and it seems to work fine.
Essentially in video_filter.codecs.inc doing a search for "$video['source'] = 'http:" and removing the "http:"
I'll have to see how further testing goes.

Tested and seems to be working well with YouTube videos. Am now able to include them on an SSL site without issue.

Is it because not all of the services support "https" that all http can be removed?

StatusFileSize
new2.8 KB

I have created a patch for the Drupal 6 version of the module though there seems to be very little difference if any.

ollu, by removing "http" or https" from the beginning of a url and simply starting with "//", the URL will pick up whatever the current protocol is. This is referred to as making the code protocol agnostic. This way if they Drupal page is being served up securely, the video will be served securely as well.

Issue summary:View changes
StatusFileSize
new9.4 KB

Here's another patch which just makes all the codecs http/https agnostic rather than just youtube.com

Just popping in to say the patch in #28 works as designed. Videos now work on http and https. Thanks.

Version:7.x-3.1» 7.x-3.x-dev

Fixing version.

ultimateboy, which services did you try? I'm afraid of making everything schema agnostic because some services might not support both http and https. If a service doesn't support https and you attempt to connect via https you'll get no response from the server. I think it'll be much safer to only make agnostic the services we are sure support both.

I simply tested youtube. However, in my opinion, modern browsers wont display the video anyways because of mis-matched content. But I see your point. I just dont have the bandwidth to test this patch against all the services.

ultimateboy, I completely understand not having the bandwidth to test all these services. Which is why I suggested only enabling it for the services we know for sure, such as YouTube.

@pianomansam thanks for providing the patch. Confirmed this is working for YouTube sources.

@pianomansam for #31: which ones don't support SSL?

These ones:
http://www.streamhoster.com
http://www.teachertube.com
http://www.metacafe.com
http://www.gametrailers.com
http://wistia.com
http://www.collegehumor.com
http://gamevideos.1up.com

Sort of supports SSL:
http://blip.tv has a wildcard SSL certificate but redirects to non-HTTPS
http://www.streamhoster.com redirects to https://secure.streamhoster.com

All the others support HTTPS on their site.

@agileware, thanks for that research. If the majority support SSL, then perhaps we should have a blacklist concept that excludes non-secure hosts.

Status:Reviewed & tested by the community» Needs work

Since there are a number of video services that don't support SSL, an scheme agnostic approach does not seem like it will work, unfortunately. I'm setting this back to Needs Work as it looks like we need to hash this out more.

Personally, I believe that waiting for each provider to be reviewed is the exact opposite approach that should be taken. We *know* that because of mixed content warnings, an http video will simply *not* show on an https site. We know that switching the url to be protocol agnostic will fix this issue for any provider that supports https. If they don't support https then it doesn't matter what we do, their videos won't show on sites with https because of mixed content.

IMO, the right approach is to apply the patch that's provided and let any services that don't support https fail... cause even today, those same videos fail anyways due to mixed content.

Just my 2 cents...

@ultimateboy, you have a good point. If we use that approach, it may be good to have another conversation about better "failing" for the sites that don't support SSL.