WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 3 months ago

#33688 reopened defect (bug)

Emoji Javascript doesn't support HTTPS

Reported by: trenzterra Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.3
Component: General Keywords:
Focuses: Cc:

Description

My WordPress site is running on SSL courtesy of CloudFlare's Flexible SSL feature.

For some reason, however, the emoji javascript code that is added to each page assumes that your site URL starts with http and does not support https. I have already changed my site URL to start with https:// but it seems the emoji code does not detect this.

The javascript I'm referring to is this:

<script type="text/javascript">
			window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":".png","source":{"concatemoji":"http:\/\/www.websiteurl.com\/wp-includes\/js\/wp-emoji-release.min.js?ver=4.3"}};
			!function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56812,55356,56807),0,0),c.toDataURL().length>3e3):(d.fillText(String.fromCharCode(55357,56835),0,0),0!==d.getImageData(16,16,1,1).data[0])):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head")[0].appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings);
		</script>

Change History (5)

#1 @trenzterra
5 years ago

  • Resolution set to invalid
  • Status changed from new to closed

#2 @swissspidy
5 years ago

  • Milestone Awaiting Review deleted

#3 follow-up: @stanquinn
15 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

this exact same thing is happening to me right now.

#4 in reply to: ↑ 3 @killerbishop
11 months ago

Tested switching over to SSL and this appears to work as expected. The basis of SSL or not in the format of the URL boils down to the is_ssl() function which requires $_SERVER['HTTPS'] to be present with a value of either on or 1 - the other option is existence of $_SERVER['SERVER_PORT'] set to a value of 443. @stanquinn and OP - I would say this is likely where your problem may be. You can probably confirm if these apply in your environment by outputting the values.

#5 @markparnell
3 months ago

When using Cloudflare's "flexible" setting, the end user accesses the site over HTTPS (their connection to Cloudflare is secure) but the connection between Cloudflare and the server is loaded over HTTP. This is necessary if the server doesn't have any sort of certificate installed (though even a self-signed or expired certificate is sufficient to switch Cloudflare to "full" instead).

As such the is_ssl() check is going to report that SSL is not being used as that's what the server sees in the request from Cloudflare, even though the end user's connection is secure.

It should be quite simple to resolve this by removing the http[s]: prefix from the URL since a URL starting with // will use the same protocol as the page itself - and since that happens on the browser side of things it won't be affected by the difference at the server. Then we could avoid the is_ssl() check altogether.

I wonder too whether this has wider ramifications for is_ssl() elsewhere?

Note: See TracTickets for help on using tickets.