SSL Administration over Non-Standard Ports

Hey! Thanks for the prompt reply! Here’s the pastebin for the patch: http://pastebin.com/bs3GRaYp.

I made almost the same change on line 740, except I used isset(), though an error suppression is probably a better choice for brevity and consistency. This change makes it so that the URL including port number can be saved, but it doesn’t solve all of the problems associated with port numbers in the URL.

I found that, while the URL was rewritten correctly in many places, there were several places where the port number was added twice. That is, “src” and “href” attributes would contain URLs with “https://example.com:4432:4432” in them, which would break functionality. This indicated to me that the “https://example.com” portion was being replaced twice with my Shared SSL Host URL, and that there was some code that ignored the port number and only looked for a plain base URL to replace.

So most of the other changes I made were to the regular expressions in the process() and replace_http_url() functions that deal with recognizing and capturing the URL to replace.

I don’t think I have to tell you, but please feel totally free to make necessary changes for correctness and style if you choose to use it. Though I’d call myself a decent PHP/RegEx coder, this is my first experience with the “dirty” side of WordPress, and I didn’t read any of the developer docs or much of the core code. I very well could’ve completely missed something.

Thanks!

This version (1.9.3-dev) does not fully work, and still exhibits the doubled port number bug.

I believe the problem is in the replace_http_url() function, where we have the lines (651, 652):

$string = str_replace($this->replace_http($this->http_url), $this->https_url, $string);
$string = str_replace($this->http_url, $this->https_url, $string);

Keep in mind that sometimes, the input string ($string) contains a URL that already contains the port number.

For reference, $this->http_url is defined as (line 100):

$this->http_url = 'http://' . parse_url(get_option('home'), PHP_URL_HOST);

And $this->https_url is our Shared SSL Host (port and all).

The apparent goal of these replacements is to replace the https and http versions of the site’s hostname with the Shared SSL Host name and the https scheme in the URL contained in $string. However, when port numbers are involved, that part of the replacement target is left out, and only the hostname and scheme are replaced, resulting in duplicated port numbers.

As an example, replace_http_url() receives “https://example.com:4432/wp-admin/” as $string at some point of the page load. $this->http_url is logically “http://example.com”. But when the first replacement is issued, it replaces “https://example.com” with “https://example.com:4432”, and the function returns “https://example.com:4432:4432”.

It looks to me like the solution would be to capture the complete base URL (that is, up until the path) and just do one replacement on that, no matter what it is, with $this->https_url (and please correct me if I’m wrong/looking at it too narrowly). I’ve created a patch for the changes to get it working again: http://pastebin.com/UKDVv4Bs.

Just after I got it working, I noticed a mixed content warning. It looks like URLs in the inline Javascript are getting returned to http (with the port number). I’m investigating.

Okay, I figured out what it was.

What was happening was the first section of process() (“Fix any occurrence of the HTTPS version of the regular domain when using Shared SSL”) was taking those instances where the URL was already switched, and then replacing the HTTPS with HTTP. This resulted in some URLs like “http://example.com:4432”, which never got corrected by later code.

In my previous patch for 1.9.2, I’d made similar changes to a similar section, which in that version was at the end of process().

I’ve updated the latest pastebin (http://pastebin.com/UKDVv4Bs), and I am now free of any mixed content warnings.

Sounds great! Thanks!

Sure thing.

All of the link, script, and img URLs did not get the port number. URLs that appear in inline script were also not given the port number.

It looks like many of those 33 URLs from the previous version shouldn’t have even been replaced (they were intended to be off-site), so 21 is the right number.

Okay, I have a small patch here that clears up all of my problems. The source now shows all HTTPS URLs with ports (with no doubling), including all tags and inline script, and I have no mixed content warnings.

I changed the condition for when to replace the HTTPS version of the regular domain from being only if the SSL Host is different to if the SSL Host is different or an SSL Port is set. I also corrected what I believed to be a typo on a later line in that condition, switching the call to replace_https_url() with replace_http_url().