MU Cookies will not allow login and cause redirect loop

Viewing 7 replies - 1 through 7 (of 7 total)
  • Moderator bcworkz

    (@bcworkz)

    1 week, 3 days ago

    There shouldn’t be a cookie conflict since you have different domain names, so I suspect that this is a symptom and not the cause. You said you checked .htaccess, but not for what. Please verify it matches what is in your network setup admin screen. While you’re there, also confirm that wp-config.php has the correct rules added.

    There might be a simple explanation for the redirect loop. When you go to the login screen, ensure that the URL does not have a redirect_to= query string. If it does, remove it, including the related URL after the = sign, then reload the page.

    It’s also possible that a theme or plugin is causing a problem by not using the “redirect_to” filter hook appropriately. Since you’ve already checked for theme and plugin conflict, I’ll assume that’s not the case here.

    If you are still having difficulty, it sometimes happens that you do get logged in, but the login screen reappears as if the login failed. But if you were to then navigate directly to an admin page such as subsite.com/wp-admin/, you may find that you are actually logged in after all.

    Thread Starter sonictail

    (@sonictail)

    1 week ago

    Hi @bcworkz thanks for your reply, it’s appreciated.

    .htaccess

    Yep, we are using the WordPress >=3.5 Subdomain example as seen here Apache HTTPD / .htaccess – Advanced Administration Handbook | Developer.WordPress.org

    In fact, dropped it all back just to that. No luck here. As we’re on is using NGINX and I believe Litespeed I’m not sure if it’s configured for it, but anyways. Have checked again 🙂

        Looking at wp-config again

        Here’s the config portion, if I have this it works fine with MainSite.com

        define( 'MULTISITE', true );
        define( 'SUBDOMAIN_INSTALL', true );
        define( 'DOMAIN_CURRENT_SITE', 'www.MainSite.com' );
        define( 'PATH_CURRENT_SITE', '/' );
        define( 'SITE_ID_CURRENT_SITE', 1 );
        define( 'BLOG_ID_CURRENT_SITE', 1 );
        define( 'NOBLOGREDIRECT', 'http://www.MainSite.com' );

        The noblogredirect is the only additional line, however it does not change anything disabling.

        I did play with the cookie settings as seen here.

        define('ADMIN_COOKIE_PATH', '/');
        define('COOKIE_DOMAIN', '');
        define('COOKIEPATH', '');
        define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

        However when I enabled these lines in the wp-config, it entirely locked me out of the whole setup. I got the same symptom of endless redirect loop. The interesting part is that I got the redirect URL you mentioned.

        https://mainsite.com/wp-login.php?redirect_to=https%3A%2F%2Fmainsite.com%2Fwp-admin%2F&reauth=1

        However, removing it did nothing. Killing those define cookie path lines stops this issue entirely.

        Hoping for cookie to actually be active?

        This was one of the first things to try, yep I’ve seen it too. However in this case we have no luck. Just loops back to wp-admin.

        So I’m gonna explore two potential solutions.

        1. I think I might try turning off all plugins on both sites, see what happens.

        2. Install a clean subsite. See what happens.

        Thread Starter sonictail

        (@sonictail)

        1 week ago

        Huh, just got this which might be just AI garbage generated from the webhost.

        Thank you for testing that change. This behavior confirms a cookie domain mismatch—using define(‘'‘COOKIE_DOMAIN', $_SERVER[‘'‘HTTP_HOST‘'‘]); restricts sessions to the current subdomain, which is why you can only log in to subsites, not the main site.

        For WordPress Multisite with subdomains, the recommended approach is usually to omit the COOKIE_DOMAIN line entirely from wp-config.php. WordPress should then handle cookies across all subdomains automatically.

        And wants me to just add

        define('ADMIN_COOKIE_PATH', '/');
        define('COOKIEPATH', '/');
        define('SITECOOKIEPATH', '/');

        However, that did not fix the issue.

        Moderator bcworkz

        (@bcworkz)

        1 week ago

        Are you using subdomains or totally different domain names for sub-sites? What your host said is true for subdomains, but not different domain names. Different domain name cookies should coexist and you should stay logged into both sites. At least until the auth cookies expire of course.

        If you’re on nginx, I don’t think the .htaccess file is valid and you need a valid version of the equivalent nginx directives. I don’t know much about nginx, but that’s my understanding.

        It’s not recommended to rely upon handbook examples for proper .htaccess and wp-config.php directives. There can be differences depending upon your specific configuration. You should rely upon what your own WP network settings tells you to do.

        I might try turning off all plugins on both sites

        Always worth a try since any one could alter the “redirect_to” filter’s returned URL. Also while doing so, switch to one of the default Twenty* themes since themes can also alter the same filter. We know unmodified default themes don’t do this.

        Long shot… as a test, try disabling JavaScript in your browser. It’s possible for a JS script to cause redirects and/or instantly expire cookies. Being disabled can break other functionality, but if a script were the cause, you should at least be able to login. Then you may re-enable JS. If a script is the cause, your next task is to identify the responsible script since disabling JS isn’t a reasonable solution.

        Thread Starter sonictail

        (@sonictail)

        6 days, 17 hours ago

        Talk about aggravating.

        1. they’re whole domain names for the sub sites. That does make sense, but you can cross login from the MU root menu.
        2. There’s usually a translation layer so at least some of .htaccess can be used. But depends on install, here I confirmed it is not installed.
        3. yep, disabled theme and plugins again. No dice.
        4. left it all disabled and turned off javascript, again no dice.

        So somehow I think I almost fixed it.

        1. Add ‘define(‘COOKIE_DOMAIN’, $_SERVER[‘HTTP_HOST’]);’ single directly below the rest of the multisite definition in wp-config.
        2. Clear the cache.

        That appears to allow multiple site dashboards at once.

        However, slight issue. now you cannot jump between sites using the My Sites > Site > Dashboard link, it boots you out to the login. BUt you can log straight back in.

        Thread Starter sonictail

        (@sonictail)

        5 days, 19 hours ago

        As I realise, the link from the dashboard to the other sites won’t work due to cookies. As they’re different domains.

        That’s a helluva showerthought.

        So I think this is done, the position of Cookie_Domain matters a lot!

        Moderator bcworkz

        (@bcworkz)

        5 days, 15 hours ago

        the position of Cookie_Domain matters a lot!

        Yes, but only to the point that it’s before WP sets auth cookies. Unless there’s another similar define() statement somewhere. But that should throw a warning since PHP does not allow redefinition of constants. As a non-fatal error, it may go unnoticed in many situations.

        you can cross login from the MU root menu

        (without the constant defined)
        I think this works because the back end is all the same code base, which site it’s operating on is managed by a global variable. The domain mapping is more of an alias than a truly separate site. By making a different domain request from “outside”, it throws WP into an endless redirect loop in trying to resolve the alias. Once the constant is set, it negates the ability to work as an alias.

        Probably not totally accurate but the fact remains you cannot have it both ways, it has to be one way or the other.

      Viewing 7 replies - 1 through 7 (of 7 total)

      You must be logged in to reply to this topic.