Redirect loop using multi site privacy and cdn

Multi site privacy plugin sets the following url
https://domain.us/wp-login.php?privacy=4&redirect_to=https%3A%2F%2Fcngidev.us%2F

if you go to https://domain.us you are sent to above url. When you supply credentials it tries to redirect to https://domain.us.
Using Cloudflare CDN this results in redirect loop until defender bans the IP after a few tries.
If any other url say https://domian.us/about is used you are correctly ask for credentials and redirected to the correct page with NO redirect failure.
This happens only at the base url. If I set CF in developer mode it all works correctly. I could understand if ALL redirects failed but they don't only the https://domain.us will fail.

Any ideas why?

  • Patrick Freitas

    Hi Lee

    Sorry to hear that you are having this issue.

    I tried to replicate on my website but had no luck.

    Wouldn't you mind please, grant the support access and we can take a closer look for you?

    1. Log in to the WordPress Admin Panel for your site (go to the Network Admin dashboard if on Multisite), and then navigate to the “Support” page from the WPMU DEV menu item (WPMU DEV > Support).

    2. Click the “Grant Support Access” button in the Support Access panel.

    https://premium.wpmudev.org/docs/getting-started/getting-support/#chapter-5

    Let us know when support is granted.
    Best Regards,
    Patrick Freitas

  • Lee

    This is not about the site it is about CLoudflare and how cache and page rules interact with wpmudev "multisite privacy" plugin (MSP). If you don't have any CF rules then no you can't reproduce this problem.

    I have 3 free rules
    *domain.tld/wp-admin* - no cache
    *domain.tld/*preview=true* - no cache
    *domain.tld/* - cache everything

    I have been trying to get all pages of https://domain.tld/ to be cached by CF and use the privacy plugin using just a password. The last choice under setting->reading->Site Visibility that MSP adds to the menu. Not a user login just a password.

    What I have determined is if Cloudflare caches the home page with a rule like
    *domain.tld/*
    then you can NOT login but are caught in a loop of password request.

    If I do not cache the home page using a rule like
    *domain.tld/*/* (page rules do not use regex so a ".*" won't get you 1 char plus wild card)
    I tried this just to avoid home page and try to catch any other page.
    Then using this rule that avoids caching the home page ie. domain.tld/ then MSP works just fine.

    So it seems to me cache and MSP can't work together as MSP is implemented. Any thoughts?

  • Lee

    [21-Dec-2018 15:08:45 UTC] PHP Fatal error: Uncaught Error: Call to a member function add() on null in /var/web/site/public_html/wp-content/plugins/sitewide-privacy-options/sitewide-privacy-options.php:359 Stack trace: #0 /var/web/site/public_html/wp-includes/class-wp-hook.php(286): additional_privacy_login_message('') #1 /var/web/site/public_html/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array) #2 /var/web/site/public_html/wp-includes/plugin.php(453): WP_Hook->do_action(Array) #3 /var/web/site/public_html/wp-login.php(111): do_action('login_head') #4 /var/web/site/public_html/wp-login.php(989): login_header('Log In', '', Object(WP_Error)) #5 /var/web/site/public_html/wp-content/plugins/wp-defender/app/module/advanced-tools/controller/mask-login.php(222): require_once('/var/web/site/p...') #6 /var/web/site/public_html/wp-content/plugins/wp-defender/app/module/advanced-tools/controller/mask-login.php(71): WP_Defender\\Module\\Advanced_Tools\\Controller\\Mask_Login->_showLoginPage() #7 /var/web/site/public_html/wp-includes/class-wp-hoo in /var/web/site/public_html/wp-content/plugins/sitewide-privacy-options/sitewide-privacy-options.php on line 359

  • Patrick Freitas

    Hi Lee

    How are you today?

    Sorry for the delay here.

    I made some tests on my end using those rules

    I have 3 free rules
    *domain.tld/wp-admin* - no cache
    *domain.tld/*preview=true* - no cache
    *domain.tld/* - cache everything

    Using our plugin I had the same issue with a password.

    then you can NOT login but are caught in a loop of password request.

    However, I made a debug on my website, and didn't get this error:

    [21-Dec-2018 15:08:45 UTC] PHP Fatal error: Uncaught Error: Call to a member function add() on null in /var/web/site/public_html/wp-content/plugins/sitewide-privacy-options/sitewide-privacy-options.php:359 Stack trace: #0...

    This seems to be a conflict with another plugin, I suggest you run a plugin conflict test and check which plugin is conflicting, and find the one that is making this conflict.

    After removing our plugin, my front end had

    This page isn’t working ++++++.com redirected you too many times.
    Try clearing your cookies.
    ERR_TOO_MANY_REDIRECTS

    Using CouldFlare without page rules both front-end and password works fine.

    Following some articles, give a try on rules using HTTPS, seems to fix the problem on my end.

    https://*domain.tld/wp-admin* - no cache
    https://*domain.tld/*preview=true* - no cache
    https://*domain.tld/* - cache everything

    If the problem persists, please, contact the Cloudflare support and check why those rules are causing the problem on your site.
    Best Regards,
    Patrick Freitas

  • Lee

    1. conflict is with defender and/or cf plugin you don't get the error all the time. i am running now with no php errors as long as you don't end up in death spiral.

    2. of course if you turn off cache and page rules it all works. the whole point is to be able to cache and page rules. MSP plugin doesn't handle it correctly.

    i showed work around using page rule *domain.tld/*/* cache everything sovles the problem but then your frontpage will never be cached.

    3. MSP needs to set a session var loop counter and take smart redirect action instead of spinning to death. If developers don't add loop recognition you can never use this plugin with CF or any other CDN.

  • viobru

    Hi, Lee!

    Hope you are doing great :slight_smile:

    I tested this on 2 of my testing sites, but I'm not able to replicate the issue. I'm not getting a redirect loop on any of them when trying to access the homepage. I just enter the MSP password and the page loads fine.

    I have this scenario on both sites:
    - Only plugins currently active on the site (network-activated): Multisite Privacy, Defender and the WPMU DEV Dashboard.
    - WP Settings > Reading > Site Visibility > Anyone that visits must first provide this password.
    - Page Rules applied to both sites on CloudFlare:
    *domain.com/wp-admin* - Cache Level: Bypass
    *domain.com/*preview=true* - Cache Level: Bypass
    *domain.com/* - Cache Level: Cache everything
    - Clouflare > Crypto > SSL > Full (strict)

    I also confirmed that the homepage was cached by CF by running the command "curl -svo /dev/null http://<your_URL>".

    Could you please check if I might be skipping something?
    If not, and those are all the settings required, then this has to be related to something else on your end. In that case, could you please try running a plugin conflict test to discard this to be related to another plugin?
    You can find information about how to run a conflict test here.
    Please, make sure you have a COMPLETE and UPDATED BACKUP of your site before running the conflict test.

    Many thanks in advance and Happy New Year!

    Kind regards,
    Violeta

  • Lee

    1. 2 or more qualified domains going to different sites on one multisite install using https://domain.tld urls most of mine have 3 domains and very easy to produce problem.
    2. use normal browser not incognito. but will happen in incognito when looging into multiple domains.
    3. login multiple times to both domains. 1st time often worked.
    4. browser cache setting? your cf page rules do not do anything with browser cache.
    5. To make failures worse turn on defender advanced logon with redirect to page other than frontpage domain default. you have to have a page or two of content.

    again we should not have to eliminate the world just to make MSP work in A virgin load. MSP needs smart redirect in session var to avoid any potential conflicts.

    I currently am defender blocked on my test system due to MSP test just now and not in office until Thursday to access work arounds.

  • Patrick Freitas

    Hi Lee

    Hope you are doing well.

    *domain.tld/wp-* - no cache
    *domain.tld/*preview=true* - no cache
    *domain.tld/*/* - cache everything

    I've tested the above rules and worked fine on my end; I can confirm my front page was cached too.

    Also Using Defender with masked URL and Multisite privacy plugin I had no redirect problem as well, I tested multiple pages and subsites, all good.

    If you would like to send us the Site/CloudFlare credentials we can take a closer look for you.

    Note: Don't leave your login details in this ticket.

    Instead, you can send us your details using our contact form https://premium.wpmudev.org/contact/#i-have-a-different-question:

    Subject: "Attn: Patrick Freitas"

    - Site login URL:

    - WordPress admin username:
    - WordPress admin password:

    - CF credentials:

    -User:
    -Pass:

    - FTP/SFTP credentials

    Host:
    Username:
    Password:
    Port:

    - cPanel credentials

    Host:
    Username:
    Password:

    - Folder path to the site in question:

    - Link back to this thread for reference

    - Any other relevant URLs/info:

    Please, reply to the ticket once you have sent the information.
    Best Regards
    Patrick Freitas

  • Lee

    using this rule you can not cache front page
    *domain.tld/*/* - cache everything
    Your domain.tld/ is your frontpage not domain.tld/frontpage etc.
    With */* your default frontpage will not be cached with CF

    Did you follow any of my previous reply? ARe you using real domains???

    There is nothing to look at at the free CF using it in default mode.

    You have browser cache or page rules for the rest of cache.

  • Kasia Swiderska

    Hello Lee,

    My teammates are using real domains for their tests.

    Please enable support access to the site where you are having this issue so we can have closer looks on your settings. It will help us narrow down this problem since we are not able to replicate.

    It would really help if you would also let us look on your CF account.

    To enable support access you can follow this guide here:
    https://premium.wpmudev.org/docs/getting-started/getting-support/#chapter-5

    Please respond in this ticket once access is granted.

    kind regards,
    Kasia

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.