Make WordPress Core

Opened 9 years ago

Closed 4 years ago

#33688 closed defect (bug) (duplicate)

Emoji Javascript doesn't support HTTPS

Reported by: trenzterra's profile trenzterra Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: Emoji Keywords:
Focuses: Cc:


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:\/\/\/images\/core\/emoji\/72x72\/","ext":".png","source":{"concatemoji":"http:\/\/\/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);

Change History (6)

#1 @trenzterra
9 years ago

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

#2 @swissspidy
9 years ago

  • Milestone Awaiting Review deleted

#3 follow-up: @stanquinn
5 years 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
5 years 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
4 years 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?

#6 @desrosj
4 years ago

  • Component changed from General to Emoji
  • Resolution set to duplicate
  • Status changed from reopened to closed
  • Version changed from 4.3 to 4.4

This looks like it was fixed as apart of #35376 in [36249] and was shipped as a part of version 4.4.2. Since then, the Emoji related URLs have been using https at all times.

Though this ticket was created first, I am going to close this out as a duplicate since a fix was already committed.

Note: See TracTickets for help on using tickets.