Domain Mapping Conflicting with Password Protected Posts

Hi - we're noticing that Domain Mapping seems to be conflicting with password protected posts. We're getting a redirect error on any site that is actually using a mapped domain and a password protected post (works fine without a mapped domain).

One thing we're seeing is that it's trying to use wp-login.php?action=postpass via HTTPS however mapped domains on our setup do not have SSL certificates.

We have the login pages set to use the original domain, and we are forcing SSL on both LOGIN and ADMIN pages.

Any thoughts? I've seen a few posts about this in the forums but none of them give a definitive fix or solution.

Thanks

  • Kasia Swiderska

    Hello James,

    I did quick test for that issue and I could not replicate - however I can see that on my site I have Cross domain login enabled? Can you check if this is also enabled for you?

    If possible would you mind allowing support access so we can have a closer look at this? Leave in support message which subsite is problematic.
    To enable support access you can follow this guide here:
    http://premium.wpmudev.org/manuals/wpmu-dev-dashboard-enabling-staff-login/

    I checked and in 2013 there was bug reported for that, but it was fixed then and I don't see any more reports there.

    kind regards,
    Kasia

  • James

    Hey Kasia,
    Thanks for the response. I'll go ahead and activate the support. We do not have 'Cross-domain autologin' active, and to be honest not sure why anyone would if the multisite has numerous users with their own sites? Unless I'm misreading the feature giving all users access to all sites seems counter-intuitive?

    The 2013 bug is the one that I was referring to, but none of the tickets actually had a solution in them, even when they were marked as resolved.

    It seems like one of the main issues with the plugin overall is it's reaction to having a forced SSL admin/login with the original domain, and then having the potential of having a NON SSL front end domain mapped. We've had to write numerous scripts to combat this issue and the way it interacts with plugins (especially jetpack).

    I have activated support on our staging site and left a message for you in there. Please let me know if you need anything else - thanks for taking the time to look in to this.

  • Nithin

    Hi James,

    Hope you are doing good today. :slight_smile:

    EDIT:

    We do not have 'Cross-domain autologin' active, and to be honest not sure why anyone would if the multisite has numerous users with their own sites? Unless I'm misreading the feature giving all users access to all sites seems counter-intuitive?

    Cross domain autologin will only log users to their mapped domain, unless you don't want that feature, you don't have to enable it. But it would be helpful, to check whether switching to cross domain autologin temporarily, makes any difference, or not.

    I checked your website, and I could notice that your mentioned subsite somehow seems to be loading in SSL, once I proceed to your website in unsafe mode, through the browser. The password protected post seems to work fine.

    I checked the domain mapping settings, and I don't see you forcing SSL there, nor through any other plugins. I suppose your using custom rules in .htaccess? If yes, could you please disable that temporarily, and check whether enabling Force http/https (Only for original domain) option, under Settings > Domain Mapping helps.

    This option will only enable https in the dashboard side, and forcing http in the frontend should load the website in http. If there is any specific reason(maybe to make Jetpack work?) for adding the custom rules in htaccess, could you please share the code, so that we could give a closer look.

    Please advise if I had missed out anything, so that we could have a better idea about this issue. Have a nice day. :slight_smile:

    Kind Regards,
    Nithin

  • James

    Hi - Can you explain more about the pros/cons of having 'cross domain autologin' turned on and what exactly it does? Turning it on doesn't seem to work either way, or at most it's intermittent - not entirely sure why though or if this is a potential security risk having this on?

    As of right now, we force https in login and admin pages set to ON which I feel is pretty standard and more or less expected? We also have the following in WP Config:

    define('FORCE_SSL_ADMIN', true);
    define('FORCE_SSL_LOGIN', true);

    Which I think is also pretty standard considering the sensitive data being passed?

    There is nothing specific in our .htaccess file that redirects to HTTPS - just in our wp-config file and within the domain mapping plugin settings. I have added more notes to the support area in our dashboard and setup a brand new site with a new subdomain and no extra plugins active so it's a cleaner test, but right now it doesn't seem to work.

    Please let me know if you are able to take another look or if you need anything else from me.
    Thanks
    -Jim

  • Rupok

    Hi James,

    Thanks for granting Support Access. I could see the issue in action in your site only when I've not temporarily Accepted the SSL Exception. Please check the attached screenshot for reference.

    This is happening because your "wpmudev.fana*******ive.com/" site doesn't have any real SSL configured. You said you have added "define('FORCE_SSL_ADMIN', true); and define('FORCE_SSL_LOGIN', true);". That's why, any query to your admin or login panel is redirected over SSL. Now when you try to visit a password protected post, probably it gets redirected through the login panel for that password authentication and then automatically opens your post when password is entered, but as your mapped domain is not under SSL, it get's stuck in the middle.

    So the solution will be installing any real SSL certificate for your mapped domain too and then change the mapping schema for your mapped domain from HTTP to HTTPS. That will make your site more secure and at the same time, this issue will be resolved.

    If you think purchasing SSL certificate for multiple subdomains will be costly for you, you can get a free SSL Certificate from Let's Encrypt. You will get a tutorial on configuring Let's Encrypt certificate here: https://www.digitalocean.com/community/tutorials/how-to-set-up-let-s-encrypt-certificates-for-multiple-apache-virtual-hosts-on-ubuntu-14-04

    Unless I'm misreading the feature giving all users access to all sites seems counter-intuitive?

    Sorry if we were not clear about this. Actually Cross Domain Autologin doesn't give *all users* to *all sites*, rather it makes a user automatically logged in to all mapped domain *he mapped*. Suppose I'm a user of your network and I have four subsites. And I've mapped 2 subsites with custom domain. So I'll automatically be logged in those mapped sites, not all sites of the network. Our Domain Mapping Usage page says:

    Enable Cross-domain autologin if you want the plugin to automatically log you into all sites you have mapped. Will also log your users into all domains they have mapped too!

    we force https in login and admin pages set to ON which I feel is pretty standard and more or less expected?

    Obviously it's a good step for security. But forcing this through "wp-config.php" file makes it working for your whole network. And when you map a domain, that domain (mapped subsite) dashboard also become a part of your network and that's why this forcing also affects your mapped domain. But as you don't have SSL certificate for your mapped domain, things get a bit messy.

    I hope these makes sense and you understand. If you still have any confusion, please let us know. We will be glad to help further.

    Have a nice day. Cheers!
    Rupok

  • James

    Hi Rupok,
    Thanks for the detailed response. I wrote prior to your response that I'm aware of what the issue is, but asking people to A: not force SSL in admin for the network which is a pretty big security issue, or B: Require people to add SSL to their mapped domains, doesn't seem like a feasible solution? (Though I could be wrong) On top of that, because of our network/server setup, we can't just have people add an SSL cert to their domains - we'll be requiring the use of a service like Cloudflare to actually make that work.

    Of course, I'm sure there are some hooks/hacks that we can do to make this work, but I can't imagine us being the only ones that are facing this. It was shown as a ticket in the WP core forums as well: https://core.trac.wordpress.org/ticket/36179

    I'm going to respond to them to see if they are willing to share the hooks that they used. Reading through the old responses on your forums it sounds like you had once fixed this within your plugin? Not sure if the fix was something else or if something changed since then?

    Thanks for the explanation of the cross-domain login as well - that makes much more sense, though I'm not sure how that would fix this issue as with FORCE_SSL_ADMIN still on, the problem will still remain.

    Let me know what you think
    Thanks

  • Kasia Swiderska

    Hello James,

    I did more tests on my site and cross domain login was not related to this - at the moment of my first response I wasn't aware you are forcing ssl in wp-config and not in domain mapping options only. And I also am forcing ssl on original domain and login page but only in Domain Mapping settings that is why it worked for me.
    And when https is forced through settings only not the wp-config.php password protected pages are working fine.
    Only when I added those lines to my config file I was able to replicate issue. Because I don't have contact to developer that were working on this thread https://premium.wpmudev.org/forums/topic/domain-mapping-not-working-with-password-protected-pages-or-post back in the days it is only my suspicion that this was fixed for forcing https in Domain Mapping settings and that was issue there.
    So if we look at that this way - it was fixed and that fix still works. I'll ask our current developer if I'm right here.

    kind regards,
    Kasia

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.