Users logging in on subdomain aren't being logged into main site

Users who login through their subdomain aren't being logged in to the main site. I'm using Pro Sites. What other information might I be able to provide that would be helpful?

  • Tyler Postle

    Hey e,

    Hope you're doing well today and thanks for your question!

    This is common behaviour in a subdomain multisite depending on your server/browser security. Mine act the same way.

    Are you able to login through the main domain with your user and have access to all subsites?

    Have you tried turning "cross domain auto login" to yes in your domain mapping settings as well?

    Look forward to hearing back e!


  • Tyler Postle

    Hey e,

    Thanks for getting back to me. I believe this is the standard behaviour by WordPress unless I'm mistaken here, been looking further into this.

    Can you try adding this to your wp-config.php file.

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

    Let us know if that makes any difference for you :slight_smile:

    Look forward to hearing back!


  • e

    By adding the cookie_domain, it allows you to be logged into the main site when you login to the subdomain. However, this prevents any login at all from mapped sites (and thus also breaks the cross domain feature). Did that answer your question?

    Also, for clarification, does the cross-domain authentication feature extend to mapped domains?

    Thanks for the kind words, Michelle :slight_smile:

  • Michelle Shull

    Hi there, e!

    I've done some digging around, and cross-domain authentication is designed to work with mapped domains, so the behavior you're seeing isn't supposed to happen, to the best of my knowledge.

    I think this may end up being an issue for the next level of support, but would you mind if I took a quick look under the hood first? If this is ok, just grant me temporary admin access to your site by clicking "Grant Access" button in the WPMU DEV Dashboard Settings from the following path and reply on this thread after granting it?

    Admin -> WPMU DEV -> Support -> Support Access Tab

    If you have not installed WPMU DEV Dashboard plugin yet, kindly do that here : and then allow access as per the above process.

    Thanks, e!

  • e

    Ms. Shull,

    I've made the installation accessible, thanks for that.

    I've reconfigured a few things to make the cross domain authentication work, however, it doesn't seem to be working for the subdomains now.

    For example:

    I login through, which forwards me to my buddypress profile page (I'm using buddypress and multisite).

    We have a link up at the top that links to the user's dashboard -

    However, even though I'm logged in properly on, it forces me to login against at

    I can give you one of the user's passwords for you to test this flow yourself, but I can't find a way to send you a response privately.

    Thanks a million!

  • Michelle Shull

    Hi again, e!

    I took a look around, and I was able to go from dashboard to dashboard without being logged out, but I did see the issue when I tried to visit a site front end.

    I am suspicious of this plugin you have installed:

    It's been around, unupdated, for while, and it doesn't look like it's actively supported. I know there have been updates and bug fixes in multisite since the last update of this plugin, so it may be worth a try to disable it and see if anything gets sorted out.

    To jot me something privately, you can use our contact form:

    Subject: "Attn: Michelle Shull"
    -WordPress admin username
    -WordPress admin password
    -login url
    -FTP credentials (host/username/password)
    -link back to this thread for reference
    -any other relevant urls

    Select "I have a different question" for your topic - this and the

    subject line ensure that it gets assigned to me :slight_smile:

    If deactivating that plugin doesn't do anything, send me the login info via the form. I'm on for a few more hours tonight, so I should be able to get it. : )

    Thanks, e!

    • e

      I think we might be confusing issues. The front end of the site is locked down intentionally. That's separate and intended behavior. The reason you can go from site to site, I imagine, is because you logged in through the primary domain (scoping the cookie to the root, and thus logging you in automatically on each subdomain - so cdsso wasn't necessary). However, if you follow the login chain that I indicate above, for whatever reason subdomains aren't being logged in automatically, although I'd expect cdsso to have taken care of that. I'll send you the login and password as requested so you can experience it for yourself.

      I don't think that plugin is the issue. It's fairly basic and only controls plugin activation, which is why it hasn't needed to be activated. Scribu is a solid dev, and these plugins are used in many base dev stacks.

      Thanks a million!

  • Tyler Postle

    Hey e,

    Hope you're doing well today and thanks for getting back to us!

    I have been testing this out on each of my multisite sandboxes and got it working how you like. I didn't add anything to the wp-config.php file. All I did was select "Mapped domain" for "login mapping" and cross domain login to Yes.

    Now when I log in to my subsite at - I have no problem visiting or any other subsite dashboard that the user is apart of.

    Try that out and let me know how it works :slight_smile:

    All the best,

  • e

    There are two issues at play here, and fixing either one will give me a workable solution.

    1) Domain mapping doesn't log you into the subdomain (original site) in addition to the mapped domain. If you configure it the way you're suggesting, you will have to re-login if they access the subdomain. Yes, you will be logged into the primary domain as well as the mapped domain.

    2) I'd really like to force them to use the original domain to login - however, when I do that, domain mapping doesn't log you into the root domain properly. I like this option because it allows me to force SSL. However, not being logged into the primary site is an issue.

    What I don't understand is this:

    "any other subsite dashboard that the user is apart of."

    Does that mean you were able to login through the mapped domain, and access any of the subdomain'd sites without issue?


    Hey @e

    Does that mean you were able to login through the mapped domain, and access any of the subdomain'd sites without issue?

    From reading Tyler's post above, seems to me that the answer to your question is:
    a) yes
    a1) if when you say 'any' you mean: only the sites "that the user is apart of."

    For your other points, are you saying that you want:

    1) users to login via 'orginal' address HTTPS address rather than HTTP 'mapped' address?
    2) and also be logged in to the primary network site?

    Like this?

    User visits mapped site frontend at:
    User login & administration at:

    And after user has visited the mapped address and logged in at the original address, they should be logged in to both the subsite and also the primary network site (also meaning that they are logged in to any other network subsites they are a part of)?

    I am looking at doing a similar setup (though I use subdirectories).

    I haven't gotten to user testing it yet, but I have what I figure is the right set of DM settings to make this happen and would love to know if you've already tried them... I'll attach screenshots of what I figure is correct, perhaps you could post yours as well for clarity?

    Kind Regards,

  • e

    "From reading Tyler's post above, seems to me that the answer to your question is:
    a) yes
    a1) if when you say 'any' you mean: only the sites "that the user is apart of.""

    Respectfully, I'd rather wait for the original poster for clarification, because that is not behavior I've been able to replicate. And "the user is apart of" does that mean in any capacity, not just admin?

    "And after user has visited the mapped address and logged in at the original address, they should be logged in to both the subsite and also the primary network site (also meaning that they are logged in to any other network subsites they are a part of)?"

    Yes, that is what I would like, but it doesn't work. When you login to the subdomain, you don't also get logged into the primary (root) domain. The distinction between subdirectory and subdomain could very well be the case. In that circumstance, you'd have to control the COOKIE_PATH rather than COOKIE_DOMAIN.

    There aren't that many options, and trust me, I've tried them all.

  • Michelle Shull

    Hi e, and also TiVism/Max!

    I don't want to put words in Tyler's mouth, so I'm going to let him check in here with you when he comes online in a few hours.

    Since it looks like his solution isn't working for you, and, like you say, you've tried a lot of options and configurations, let's call in our second level support guy, Jose, and see if maybe he can give us some insight.

    Thanks for your patience, e, and thanks for jumping in, Max! We've been swamped and understaffed, thanks so much for taking the time to offer this reply.

  • e

    OK - so the behavior in particular I'm trying to achieve is this (subdomain setup): = mapped domain = original domain = primary domain

    When I log into either and, it should log me into all 3.

    I'm tracking the redirects and headers, and it seems I'm only being redirected twice. Can someone with an installation who can match the behavior stated above track the redirect headers and let me know their contents? Better yet, if you could post the urls of the redirects, that would be helpful as well.

    Mine are:
    ?action=domainmap-propagate-user&auth=user|1469324312|oil84UpfRapxm34lk34n6l346oozimXpZqfXtq|3633049j63lk4ngl34ho34h31909242377784e8a41c0464c861f08f845 (I changed the actual contents of the url)


  • e

    OK - I think I figured this one out. It was brutal, so hopefully this will enlighten someone in the future that might be having similar problems.

    I dissected the headers of the initial login and every single redirect. Because of the way the plugin redirects, our Varnish config was treating the redirect as cacheable. It was actually caching the second redirect. I never noticed this because the cached redirect was correct. This did, however, prevent the final redirect from happening as it should have.

    I figured it out by outputting the varnish cache status into the headers to troubleshoot, and noticed undue caching on the redirect.

    NOTE TO ANYONE THAT READS THIS: The SSO feature is redirect and cookie dependent. Be careful with your front end proxy. WordPress uses cookie based auth, so you don't have to worry about sticky sessions, but those redirects and cookies must be set properly, or it won't authenticate cross-domain.

  • e

    @TiViSM Thanks bud!

    There are two Chrome plugins that I used to troubleshooting.


    Live HTTP Headers will output the headers for any site you have open in your browser, so make sure the page you're wanting headers from is isolated, especially if you have another page making AJAX calls.

    HTTP Headers is a bit more manageable, but only shows you the headers for the current chain, so I used a little of both to figure out what was going on.

    Without having your hosts Varnish setup, it's really hard to know what might or might not be happening. Most hosts are smart enough to "pass" admin-ajax.php requests. Some hosts will explicitly whitelist admin-ajax, others will whitelist with something like:

    req.http.X-Requested-With == "XMLHttpRequest"

    If this isn't happening, you're dead in the water.

    The second thing would be to make sure the host isn't manipulating the Pragma and Cache-Control headers. Because no-cache headers are default on almost all pages, signed in or not, and many Varnish setups will honor Pragma and Cache-Control settings, most WP hosts have to explicitly redefine those headers. The problem is, they need to make sure certain actions are whitelisted, such as 302s. I've personally chosen not to cache 301s, but most individuals will say 301s are safe to cache.

    One thing that I found creeping in when I was customizing my Varnish config was PHPSESSID cookies being set, which dependent on some rules, will be considered a live session, and preclude caching. WordPress uses cookie based sessions out of the box, so you don't need this cookie. (Some plugins supposedly use it, but I've yet to run into one - and I'd be wary of any plugin that used it knowing the "WP Way" anyways). Make sure the Varnish cache is properly dumping your cookie so it's actually cached.

    Personally, I have some if-elseif statements that set a cache header that only I can see that tells me the status of the cache, and if it was invalidated or a "MISS," why. It's really difficult to troubleshoot someone else's Varnish, so I'd do a little research myself and armed with that diligence, talk to your host and have them help figure out what the issue might be.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.