Domain Mapping Introduces Mixed Content Loading on HTTPS subdomains

Hello,

On WP 4.8 multisite network when Domain Mapping is activated, wp-login.php fails on all subsites with HTTPS and which have no mapped domain, thus making login impossible. Users are effectively locked out of all subsites without mapped domains

Deactivating Domain Mapping eliminates the issue and login works as expected on all subsites without mapped domains.

When Domain Mapping is activated, then browser mixed content warnings are present on subsites without a mapped domain and login fails even if the unsafe scripts are allowed.

The browser warns that unsafe scripts are attempting to be loaded; however, all unsafe items listed seem to be located on the HTTPS domain of the subsite.

Subsites with mapped domains seem to behave ok, but subsites without a mapped domain cannot be logged into.

This issue began after 4.8 which made BIG changes to wp-login in order to allow site login using wordpress.com credentials.

Interestingly, a workaround to gain access to the subsite dashboards while Domain Mapping is active and causing this issue is as follows and once the Jetpack feature for login with wordpress.com credentials is activated and configured, then Domain Mapping can be reactivated so all the mapped sites on the network behave and each site with the Jetpack alternate login feature active can be accessed using that login but NOT REGULAR LOGIN

1) Disable Domain Mapping
2) Log in to a subdomain site that has no mapped domain.
3) in site dashboard Jetpack Settings security tab activate "allow login with wordpress.com credentials)
4) simultaneously visit wordpress.com and access the same subdomain site through wordpress.com and perform a full sync of the site
5) In wordpress.com dashboard in the Jetpack Settings security tab activate (or make sure it is already activated) "allow login with wordpress.com credentials"
6) return to subsite and login is possible using wordpress.com credentials

It appears something in Domain Mapping is calling for an HTTP connection even on HTTPS subsites without mapped domains.

Any assistance will be appreciated.

  • Kasia Swiderska

    Hello SooBahkDo,

    Would you mind allowing support access so we can have a closer look at this?
    To enable support access you can follow this guide here:
    https://premium.wpmudev.org/docs/getting-started/getting-support/#chapter-4

    Please respond in this thread once access is granted.

    I'm asking this because I tested on my site with WP 4.8 and Domain Mapping and I could not replicate the issue.

    kind regards,
    Kasia

  • Rupok

    Hi SooBahkDo,

    I can see that our developers are working on that bug and I believe, they will come up with a solution soon. We will update you as soon as we get anything from them.

    Please keep in mind, our developers work around the clock and they have to deal with lots of critical issues and other things. So it may take a little while for them to check this and release a fix.

    I appreciate your patience.

    Have a nice day. Cheers!
    Rupok

  • SooBahkDo

    Additional Information:

    With domain mapping active, these are the browser console errors reported when accessing a subsite on the network which does not have a top level mapped domain.

    **Removing the plugin Domain Mapping via FTP eliminates all the following errors and login works as expected.**

    Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure script 'http://sub.domain1.com/wp-includes/js/jquery/jquery.js?ver=1.12.4'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:1 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure script 'http://sub.domain1.com/wp-includes/js/jquery/jquery-migrate.js?ver=1.4.1'. This request has been blocked; the content must be served over HTTPS.
    jetpack-sso-login.js:1 Uncaught ReferenceError: jQuery is not defined
    at jetpack-sso-login.js:1
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:21 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-includes/css/dashicons.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:22 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-includes/css/buttons.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:23 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-admin/css/forms.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:24 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-admin/css/l10n.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:25 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-admin/css/login.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:133 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'http://sub.domain1.com/wp-login.php'. This endpoint should be made available over a secure connection.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:1 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-includes/css/dashicons.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:1 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-includes/css/buttons.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:1 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-admin/css/forms.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:1 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-admin/css/l10n.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.
    wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-d…:1 Mixed Content: The page at 'https://sub.domain1.com/wp-login.php?redirect_to=https%3A%2F%2Fsub.domain1.com%2Fwp-admin%2F&reauth=1&jetpack-sso-show-default-form=1' was loaded over HTTPS, but requested an insecure stylesheet 'http://sub.domain1.com/wp-admin/css/login.css?ver=0b17e73f815ebed57a54cb43907097de'. This request has been blocked; the content must be served over HTTPS.

  • SooBahkDo

    Hi fred,

    Thanks for the suggestion.

    I implemented the code change you suggested; however, I am still encountering the following errors on the login page.

    Blocked loading mixed active content “http://institute.soobahkdo.org/wp-includes/js/jquery/jquery.js?ver=1.12.4”[Learn More] wp-login.php
    Blocked loading mixed active content “http://institute.soobahkdo.org/wp-includes/js/jquery/jquery-migrate.js?ver=1.4.1”[Learn More] wp-login.php
    Blocked loading mixed active content “http://institute.soobahkdo.org/wp-includes/css/dashicons.css?ver=3479c4d3458364f2f8d152cb7f5c998a”[Learn More] wp-login.php
    Blocked loading mixed active content “http://institute.soobahkdo.org/wp-includes/css/buttons.css?ver=3479c4d3458364f2f8d152cb7f5c998a”[Learn More] wp-login.php
    Blocked loading mixed active content “http://institute.soobahkdo.org/wp-admin/css/forms.css?ver=3479c4d3458364f2f8d152cb7f5c998a”[Learn More] wp-login.php
    Blocked loading mixed active content “http://institute.soobahkdo.org/wp-admin/css/l10n.css?ver=3479c4d3458364f2f8d152cb7f5c998a”[Learn More] wp-login.php
    Blocked loading mixed active content “http://institute.soobahkdo.org/wp-admin/css/login.css?ver=3479c4d3458364f2f8d152cb7f5c998a”[Learn More] wp-login.php
    Loading failed for the <script> with source “http://institute.soobahkdo.org/wp-includes/js/jquery/jquery.js?ver=1.12.4”. wp-login.php:17
    Loading failed for the <script> with source “http://institute.soobahkdo.org/wp-includes/js/jquery/jquery-migrate.js?ver=1.4.1”. wp-login.php:18
    ReferenceError: jQuery is not defined[Learn More] jetpack-sso-login.js:1:1
    ReferenceError: jQuery is not defined[Learn More] hideShowPassword.js:11:5
    ReferenceError: jQuery is not defined[Learn More] public.js:22:1
    Password fields present in a form with an insecure (http://) form action. This is a security risk that allows user login credentials to be stolen.[Learn More]

    Do you have any other insights?

    Thanks for chiming in. :slight_smile:

  • SooBahkDo

    Hi Fred,

    That change seems to have eliminated all the console errors except for the following:

    Loading failed for the <script> with source “http://institute.soobahkdo.org/wp-includes/js/jquery/jquery.js?ver=1.12.4”. wp-login.php:17
    Loading failed for the <script> with source “http://institute.soobahkdo.org/wp-includes/js/jquery/jquery-migrate.js?ver=1.4.1”. wp-login.php:18
    ReferenceError: jQuery is not defined[Learn More] jetpack-sso-login.js:1:1
    ReferenceError: jQuery is not defined[Learn More] hideShowPassword.js:11:5
    ReferenceError: jQuery is not defined[Learn More] public.js:22:1

    You are almost my Hero: :slight_smile:

    Any other magic you can share?

    Thanks so much!

  • Rupok

    Hi SooBahkDo,

    I'm so sorry for the delay and I do apologize for this.

    The good news is - our developers have worked on this and it has already passed our QA check. So I believe, it will be included in our next Domain Mapping release. I really wish I could give you an ETA for the release, but I'm afraid, I can't give that right now :slight_frown:

    However, I'll request you to wait for a little more until the next version is released. I really appreciate your patience.

    Have a nice day. Cheers!
    Rupok

  • SooBahkDo

    I installed the beta version, but it did not resolve the issue of non-secure items.

    :slight_frown:

    It also introduced a new issue on one site which became inaccessible due to too many redirects.

    There may have been other issues on other sites across the network that I did not notice or come across because as soon as I confirmed that it did not resolve the insecure items on the login page, I removed it.

    One site reported only a single insecure item when inspecting the wordpress login page with FireFox -- a form with action originating from the HTTP: url of the site rather than the HTTPS: url of the site

    Another site with a subdomain url indicates the following as the insecure elements the page is seeking to load.
    jquery.js 200 script wp-login.php?redirect_to=https%3A%2F%XXX.XXXXXXX.ORG%2Fwp-admin%2F&reauth=1:11 33.4?KB 436?ms
    jquery-migrate.js 200 script wp-login.php?redirect_to=https%3A%2F%2XXX.XXXXXXX.ORG%2Fwp-admin%2F&reauth=1:12 8.0?KB 332?ms
    dashicons.css 200 stylesheet wp-login.php?redirect_to=https%3A%2F%2XXX.XXXXXXX.ORG%2Fwp-admin%2F&reauth=1:14 28.7?KB 383?ms
    buttons.css 200 stylesheet wp-login.php?redirect_to=https%3A%2F%XXX.XXXXXXX.ORG%2Fwp-admin%2F&reauth=1:15 2.7?KB 196?ms
    forms.css 200 stylesheet wp-login.php?redirect_to=https%3A%2F%2XXX.XXXXXXX.ORG%2Fwp-admin%2F&reauth=1:16 6.0?KB 286?ms
    l10n.css 200 stylesheet wp-login.php?redirect_to=https%3A%2F%2XXX.XXXXXXX.ORG%2Fwp-admin%2F&reauth=1:17 1.4?KB 266?ms
    login.css 200 stylesheet wp-login.php?redirect_to=https%3A%2F%2XXX.XXXXXXX.ORG%2Fwp-admin%2F&reauth=1:18 1.8?KB 266?ms

    SIGH :slight_frown:

    Guess I have go to the back of the months long que now.

  • SooBahkDo

    Hello pravdamien,

    Thanks for the workaround. In our case, some subsites are not even aware of the existence of the main site, so redirecting them is not an option.

    Our current workaround was to implement dedicated login pages on all subdomain sites and use a login plugin.

    It was painful and time intensive for us to rework every site in the network months ago all because of a bug in this premium Domain Mapping plugin.

    The time and aggravation this particular bug has cost us has outweighed the amount of time saved by other WPMUDEV benefits and is making me question the support of plugins when it takes months and months for a fix to be rolled out. Quite frankly I get better support response from a number of free plugin developers.

    Not trying to step on anyone's toes, but this issue has dragged on waaaaayyyy too long in my opinion.

  • SooBahkDo

    We have quite a few years of membership in WPMUDEV and as you said, overall consider it a value, but this particular plugin issue is surely problematic for others besides us.

    Anyone activating it for the first time on their new multisite and who encounters the subdomain login issues may finally figure out that a premium plugin wasted their time and that's gotta cast a cloud over WPMUDEV quality and value when that happens.

    That's also the kind of thing that can tick off someone enough to send them on a review and ratings rampage because they feel its their only recourse when support is unresponsive.

    I have a bit more patience in me, but I must admit I am running low on this particular matter.

    As you said, it would not be quite as bad if the functionality of the plugin were available elsewhere, but its not. To me that seems even more reason WPMUDEV would want to be sure it works flawlessly and its fixed if broken since they are the only source for it.

    When a WPMUDEV customer depends on this exclusive plugin and then can't get an update or bug fix, in a reasonable timeframe it really calls into question some of the marketing promises made recruiting members.

    Normally, I would just have our developer dig in and solve the problem, but I don't think I should have to pay WPMUDEV members dues PLUS a developer to rework WPMUDEV premium plugins.

    I also understand that development teams are busy on a huge range of projects, but leaving paying paying customers who are counting on responsive service in the lurch isn't cool.

  • SooBahkDo

    Hello Kasia,

    I installed the new beta version of Domain Mapping and tested logging into several subdomain sites on our network using Chrome Version 65.0.3325.181 (Official Build) (64-bit) and the issue appears resolved.

    I also tested using FIREFOX 59.0.2 (64-bit) and the issue appears resolved.

    However, one other issue is present that may or may not be related to the Domain Mapping plugin, but since they interact, I am reporting it. Perhaps the developer can advise if a new ticket should be opened for this issue or if another tweak is needed to Domain Mapping. We also run MULTI-DOMAINS and the dashboard column for "Wildcard DNS Availability" indicates all domains are "unavailable" except the main site. The additional domain sub sites all have DNS wildcards configured at the registrar and they have all been working fine and continue working, so this seems to be a false indication by MULTI-DOMAINS. However, I suspect this issue (like the Domain Mapping issue) is related to the fact that we converted our network to HTTPS.

    The conversion to HTTPS is what triggered the Domain Mapping issue and I suspect the MULTI-DOMAINS issue is also because of HTTPS.

    How should we proceed to address the MULTI-DOMAINS issue?

    If a new ticket is made, then we should refer to this one as the issues seem related.

    Please advise.

    Thanks.

  • SooBahkDo

    Hello Kasia,

    I'll start another ticket about MULTI-DOMAINS

    About Domain mapping:

    On some subsites, Chrome and Firefox still report insecure objects.

    You can see this issue when landing on the log in page of these sites with Chrome or Firefox:

    When insecure content is detected the login form shifts far left against the page edge.
    When insecure content is NOT detected the form is centered on the page.

    I have tried clearing caches, etc., but the only thing that seems to resolve the mixed content is a setting in the plugin Really Simple SSL Multisite as explained below.

    NOTE: One difference with this version of Domain mapping is that ignoring the mixed content warning and logging in with user name and password (without telling the browser to load the unsafe scripts) then login will succeed where it would not succeed before this version of Domain mapping.

    We are using Really Simple SSL Multisite and it has a mixed content fixer feature for the user facing side and another for the admin area. One setting for the mixed content fixer indicates that it changes the hook that is used.

    "this option makes the mixed content fixer feature fire on the INIT HOOK instead of the TEMPLATE_REDIRECT HOOK. Only use this if you are experiencing issues with the mixed content fixer."

    INSECURE MIXED CONTENT ON LOG IN PAGE
    https://r1.soobahkdo.org/wp-admin (set to fire on TEMPLATE_REDIRECT HOOK)
    https://r2.soobahkdo.org/wp-admin (set to fire on TEMPLATE_REDIRECT HOOK)
    NOTE: changing the Really Simple SSL Multisite setting to alter the mixed content fixer feature to fire on INIT HOOK eliminates the mixed content issue on these sites and any others.

    NO INSECURE MIXED CONTENT ON LOG IN PAGE
    https://r3.soobahkdo.org/wp-admin (set to fire on INIT HOOK)
    https://r4.soobahkdo.org/wp-admin (set to fire on INIT HOOK)

    Site owners who are not using Really Simple SSL are likely experiencing the same issue we are when that plugin's mixed content fixer is not configured to fire on INIT HOOK.

    Any additional input?

    Thanks,
    Phil

  • Kasia Swiderska

    Hello Phil,

    I tried to check those subsites but they are now redirecting me to another domain (.biz) and page /oooooops/

    On some subsites, Chrome and Firefox still report insecure objects.

    Please confirm if I'm getting this correctly: you have new beta installed on network where on all subsites there was this issue with insecure content - and after installing it, the problem was fixed, but not for all subsites. Some of them, in the same network are still showing this problem?

    kind regards,
    Kasia

    • SooBahkDo

      Hello Kasia,

      Not sure why you encountered the oooops page unless Wordfence is blocking you. I believe it is set to restrict admin access and perhaps your IP or country are restricted. Can you access the home page of the subsites?

      Yes, you stated the issue correctly.

      The additional factor I discovered on subsites that still have insecure content on the log in page it that the insecure content issue can be fixed when we change the setting on the Really Simple SSL Multisite mixed content fixer feature to fire on INIT HOOK rather than firing on TEMPLATE _REDIRECT HOOK.

      For other readers, I also discovered that after installing the new beta of Domain Mapping it was necessary to clear all caches in order to evaluate the consistent behavior of the new version of Domain Mapping. It behaved differently on different machines even after clearing the caches, but those behavior issues were local and linked to each machine. I think perhaps cookie issues were causing inconsistent behavior. Once we discovered that changing the setting on Really Simple SLL Multisite resolved the issue, then log in behavior soon became consistent across all machines for all sites tested so far.

  • Kasia Swiderska

    Hello SooBahkDo,

    I'm connection currently from Nepal, so it might be reason I can't see that network. But now when I try the main domain of the network I'm getting a "Error establishing a database connection"

    and now when I try to go to subdomain it sends me directly to biz site /blocked/

    Is it possible to unblock Nepal so I can see what is happening? Also can you enable support access so I can try to check why fix works on some subdomains but not others?

    kind regards,
    Kasia

  • Kasia Swiderska

    Hello Phil,

    Thanks for the access it works. I checked site and what I noticed (I haven't turned off the settings in Really Simple SLL as this is live site) that most probably issue is present for the subdomains that are from other domains than the main site domain. So the subsites in .org domain still have this issue but subsites in the .biz domain were fixed with the beta version?

    kind regards,
    Kasia

  • SooBahkDo

    Kaisa,

    When our developer was looking into the insecure elements issue, he discovered another issue that may be a contributing factor to the mixed content issue.

    "Working backwards I discovered that the Domain Mapping plugin's dashboard setting on the domain(s) mapped section, the dropdown was showing “Directed to mapped (primary) domain” (the default value on the form) HOWEVER, the value in the database was “Directed to original domain” (the default value on the front-end).

    This bug was causing sites to redirect back and forth in an endless loop between the mapped domain and the underlying sub-domain. (even though the dashboard setting indicated it was configured to use the mapped domain.)

    Once I changed the setting in the dashboard to something else and then back to “mapped” it actually set the proper value in the database for the site.

    It is probably worth notifying the plugin developers about this as it appears in the latest version of their plugin and appears to be a bug.

    I have changed this for now in the code so that the default value is “mapped” which I imagine is the one you want."