WordPress.org

Ready to get started?Download WordPress

Forums

WordPress HTTPS (SSL)
[resolved] Plugin strips HTTPS from URLs (causes mixed content warnings) (10 posts)

  1. Nyhm
    Member
    Posted 1 year ago #

    After upgrading from WPHTTPS 2.x to 3.0.3, I noticed new mixed content warnings. I've read your FAQ, but I have figured out that this is caused by some new (bad) behavior in this version:

    Your plugin now seems to be stripping HTTPS from URLs that are coded (on purpose) to be HTTPS. I think I can overcome this by use of a custom force-ssl hook (as documented in your FAQ), but I'd really like you to reconsider actively removing HTTPS when it's coded that way.

    My particular case is part of JavaScript code from Piwik:

    var pkBaseURL = (("https:" == document.location.protocol) ? "https://example.com/piwik/" : "http://example.com/piwik/");

    The first https:// turns into http:// under the new WPHTTPS plugin. Thanks for looking into this and any advice you can give. This is a very useful plugin overall!

    http://wordpress.org/extend/plugins/wordpress-https/

  2. Nyhm
    Member
    Posted 1 year ago #

    Here's the work-around that I've found for this particular case. The hook was not the answer. I changed the JS to hide the URL from your plugin, so it couldn't strip the protocol spec:

    var pkProto = (("https:" == document.location.protocol) ? "https" : "http";
    var pkBaseURL = pkProto + "://example.com/piwik/";

    This fixes my failure case, but I still think your WP-HTTPS plugin should not be altering URLs that are in the page content like this. I understand that this is a core function of the plugin, but is there a good use case for changing HTTPS into HTTP?

    Maybe consider an option to never "downgrade" HTTPS to HTTP in URLs.

    ... Just some thoughts/suggestions on how to further improve this otherwise useful plugin. Thanks for your efforts!

  3. Mvied
    Member
    Plugin Author

    Posted 1 year ago #

    If someone is using a service like CloudFlare or some other caching mechanism, pulling HTTPS resources on the HTTP page may prevent those caching services from working correctly.

    There is no reason for the plugin to change a random URL in JavaScript. Is the JS you posted hard-coded, or are you using WordPress functions to pull the site's URL?

  4. Nyhm
    Member
    Posted 1 year ago #

    Thank you for your reply. In my case, the URL is hard-coded. When I load the page, then inspect the page source (as seen by the browser), the https://example.com/... is changed to http://example.com/...

    My work-around seems to be OK, but please inform me if you can track down this behavior. I'd rather not have to rely on this work-around. Thanks!

  5. Mvied
    Member
    Plugin Author

    Posted 1 year ago #

    Now that I think about it, I know why it's happening. There's really no way to prevent it from changing the URL to HTTP. I would suggest placing the code in a separate file, or leaving it how you have it now.

  6. Nyhm
    Member
    Posted 1 year ago #

    I'm glad you figured it out! Could you please write a more detailed explanation, so I know when your plugin will alter my URLs?

    I like what your plugin provides, and I want to keep using it, but I need to understand exactly how it behaves so I can make sure my site is fully compatible.

    Thanks!

  7. Mvied
    Member
    Plugin Author

    Posted 1 year ago #

    Sure.

    https://github.com/Mvied/wordpress-https/blob/master/lib/WordPressHTTPS/Module/Parser.php#L211

    Here in the Parser module (the module that controls the output buffering processing) if the Site URL is not set to HTTPS, every occurrence of the HTTPS version of the Site URL is replaced with HTTP in the HTML output.

  8. Nyhm
    Member
    Posted 1 year ago #

    OK, I understand the explanation, and I see what the code is doing. However (back to my initial concern), why is it necessary/reasonable to change an HTTPS URL to HTTP.

    It seems to me that pages can load some resources from HTTPS even though the page itself was requested/received under HTTP.

    Your plugin makes sure that when on an HTTPS page, all URLs are HTTPS (to avoid mixed content warnings), but the other way around _decreases security_ (and breaks functionality, as my use case shows).

    I would like to request either: (a) stop downgrading HTTPS to HTTP (unless you can explain the case when this is absolutely necessary), or (b) provide an option to disable this behavior.

    Thanks for your support of this plugin! I'm very glad you're willing to help your users.

  9. Mvied
    Member
    Plugin Author

    Posted 1 year ago #

    Sure, I already explained it above.

    If someone is using a service like CloudFlare or some other caching mechanism, pulling HTTPS resources on the HTTP page may prevent those caching services from working correctly.

    I will consider an option for turning this off, however, I'd like to keep the settings minimal.

  10. Nyhm
    Member
    Posted 1 year ago #

    Ah, I see. I didn't realize that was the primary purpose of this behavior.

    I'll mark this topic as resolved, because the behavior is as you expect. I agree with keeping settings to a minimum for simplicity, yet I hope to see some built-in way of handling this case in future versions.

    From a software feature design standpoint, I'd argue that my case is the standard common case, which aught to be supported by the default behavior, and the caching/CloudFlare situation is a special-case.

    In any case, at this point, I think I have a working work-around, and I thank you for your support on this issue.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic