Domain Mapping: Cross Domain Login Not Working

I am using the Domain Mapping plugin on a site also running BuddyPress. Before I used the plugin form Donncha, but switched to this one when the cross domain login was added.

In short: domain mapping is working, but I am having to login again on each mapped blog.

Any ideas?

  • Nathan Barry

    I only had one file show up as not loading in Firebug, and that was the widget-blogs.css file for BuddyPress.

    Here is my wp-config file:


    * The base configurations of the WordPress.
    * Do not try to create this file manually. Read the README.txt and run the
    * web installer.
    * This file has the following configurations: MySQL settings, Table Prefix,
    * Secret Keys, WordPress Language, and ABSPATH.
    * This file is used by the wp-config.php creation script during the
    * installation.
    * @package WordPress

    // ** MySQL settings - You can get this info from your web host ** //
    /** The name of the database for WordPress */
    define('DB_NAME', 'shop208beta');

    /** MySQL database username */
    define('DB_USER', 'shopbeta');

    /** MySQL database password */
    define('DB_PASSWORD', '****');

    /** MySQL hostname */
    define('DB_HOST', 'localhost');

    /** Database Charset to use in creating database tables. */
    define('DB_CHARSET', 'utf8');

    /** The Database Collate type. Don't change this if in doubt. */
    define('DB_COLLATE', '');
    define('VHOST', 'yes');
    $base = '/';
    //define('CURRENT_SITE', '' );
    define('PATH_CURRENT_SITE', '/' );
    define('SITE_ID_CURRENT_SITE', 1);
    //define('BLOGID_CURRENT_SITE', '1' );

    * Authentication Unique Keys.
    * Change these to different unique phrases!
    * You can generate these using the {@link secret-key service}
    * @since 2.6.0
    define('AUTH_KEY', '****');
    define('SECURE_AUTH_KEY', '****');
    define('LOGGED_IN_KEY', '****');
    define('NONCE_KEY', '****');
    define('AUTH_SALT', '****');
    define('LOGGED_IN_SALT', '****');
    define('SECURE_AUTH_SALT', '****');

    * WordPress Database Table prefix.
    * You can have multiple installations in one database if you give each a unique
    * prefix. Only numbers, letters, and underscores please!
    $table_prefix = 'wp_';

    * WordPress Localized Language, defaults to English.
    * Change this to localize WordPress. A corresponding MO file for the chosen
    * language must be installed to wp-content/languages. For example, install
    * to wp-content/languages and set WPLANG to 'de' to enable German
    * language support.
    define ('WPLANG', 'shop208');

    // double check $base
    if( $base == 'BASE' )
    die( 'Problem in wp-config.php - $base is set to BASE when it should be the path like "/" or "/blogs/"! Please fix it!' );

    // uncomment this to enable wp-content/sunrise.php support
    define( 'SUNRISE', 'on' );

    // uncomment to move wp-content/blogs.dir to another relative path
    // remember to change WP_CONTENT too.
    // define( "UPLOADBLOGSDIR", "fileserver" );

    // If VHOST is 'yes' uncomment and set this to a URL to redirect if a blog does not exist or is a 404 on the main blog. (Useful if signup is disabled)
    // For example, the browser will redirect to for the following: define( 'NOBLOGREDIRECT', '' );
    // Set this value to %siteurl% to redirect to the root of the site
    // define( 'NOBLOGREDIRECT', '' );
    // On a directory based install you must use the theme 404 handler.

    // Location of mu-plugins
    // define( 'WPMU_PLUGIN_DIR', '' );
    // define( 'WPMU_PLUGIN_URL', '' );
    // define( 'MUPLUGINDIR', 'wp-content/mu-plugins' );

    // Uncomment to disable the site admin bar
    //define( 'NOADMINBAR', 1 );

    define( "WP_USE_MULTIPLE_DB", false );

    /* That's all, stop editing! Happy blogging. */

    /** WordPress absolute path to the Wordpress directory. */
    if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

    /** Sets up WordPress vars and included files. */
    require_once(ABSPATH . 'wp-settings.php');

  • Nathan Barry

    Yes that sounds right.

    I have mapped to the blog & mapped to (only one domain mapped to each blog). Then I have

    If I log into it creates cookies for itself and for, but not

    If I log into it creates cookies for itself, but no subdomain blog.

    It is still just one domain mapped to each blog.

    Now I was using Donncha's version of the plugin before if that makes a difference.


  • Aaron

    But if I log into the primary domain first, then click to the mapped domain, it doesn't have the needed cookies and I am not logged in on the mapped domain.

    I don't think this is a feature of our plugin.

    Then when logging into the mapped domain it creates cookies for both that and the primary domain. Then I am logged into both domains.

    That is the feature advertised as Cross Domain Logins.

    Barry, can you confirm?

  • Barry

    It should work like this: ->

    These are the orig domains and the mapped domains.

    If I log into it will automatically create the cookies for
    If I log into it will automatically create the cookies for

    if I log into (the main site) it won't create any cookies because it doesn't have a mapped domain ( does)

  • Nathan Barry

    Here is the functionality I would like to see (and what I thought I was buying):

    1. If you login to your primary domain, then you are logged into all mapped domains as well.
    2. If you login on a mapped domain, then you would also get logged into all other mapped domains.

    Now the more I think about it that is a lot of cookies to create. So maybe this would be better:

    When a user visits a mapped domain it checks to see if they are logged in on the primary domain. If they are not logged in, it does nothing (or asks them to login). If they are logged in on the primary domain it then creates the cookies for the mapped domain.

    I am not sure what the best implementation would be, that is just one idea.

    What do you think? Useful?

  • I agree something needs done because as of now, there's some functionality issues for end-users.

    mu Install =
    User Install =
    User Install Mapped =

    Our users are, for the most part, no matter how many times we tell them otherwise, logging into their dashboards from our Which, even if they have a mapped domain, auto-forwards them to their dashboard.

    Guess what? Post previews, theme previews, etc. etc. all break for a user with a mapped domain that's logged into their subdomain instead, which is where the sends them.

    Even if could auto-forward them to their mapped domain dashboard if they have one, instead of subdomain dashboard, that would solve all of those problems. Then we wouldn't have to worry about the actual mapping issues within the subdomain dashboard.

  • Barry

    Ok, this is the functionality so far:

    Log in to - logs user into,,

    Log in to - logs into,,

    That is the functionality as of the current version (2.0).

    If a user logs into, then they are also logged into, but not - primarily because they could have multiple blogs, each with a mapped domain. So either we add in the overhead of creating cookies for or checkin login status for EVERY mapped domain they have, or we can have them pick a single mapped domain that they have as their main domain and only log them into that one, OR we do nothing.

  • @Barry
    or we can have them pick a single mapped domain that they have as their main domain and only log them into that one, OR we do nothing.

    My personal opinion would be let them set a main domain and only log them into that. I think that'd take care of a lot of issues, at least issues that we are getting complaints about from end-users.

    Although could just be that we're an exception, and if other people aren't having these types of end-user problem, we need to come up with something that's more specific to our installs.

    Thanks as always for all of your work on this.

  • Barry

    Setting a main domain is a good idea. I'll look into that.

    It's tricky, I'm sure there is a way to do it, but it may take some thought.
    The only way, it seems, to see if a user is logged into WPMU is to check for a logged_in cookie on that domain. Now, obviously, if we are on we can't read the cookies for because of the in-built browser security, so we have no way to do a quick check to see if they are logged into the main site.

    If we could include a file on the domain to check that cookie, then it's not easy to pass back the yes or no to the mapped domain without opening a whole raft of potential security issues.

  • DocValerian

    perhaps this should be optional...
    it sure IS much overhead to create cookies for EVERY mapped Domain on login. But this is only a problem for large numbers of domains...

    However, I'll sure try to implement this in my site, since I really need this feature and it was the reason I signed in to this site in the first place...
    I would appreciate any hint on how to do this, which would save me some time. (create cookies for all sites, logout for all sites)

  • Barry

    To create a cookie for every domain you have to create a cookie AT every domain, from that domain.

    That means adding a file in the header of every page load, from EVERY domain (got 30 domains mapped on your site, you have to include 30 files in the header of each page) to ensure that the logged in cookies for each of those domains exists.

    I'm trying to come up with a different method at the moment, but am not 100% sure how practical it will work.

    If you want to use the existing functionality, but for all domains you will have to look at the build_cookie function (around line 178) and see how that adds the relevant file for a single domain. Change that to loop through all domains and add multiple files.

    For each generated file in the header, the function directly underneath the build_cookie function is called. This function generates and removes the relevant cookies. You should be able to leave that one alone though as it will work as is for each file load generated by the build_cookie function.

    I hope that helps somewhat. Hopefully my new method will work better than this approach, but it needs some thinking through and testing first.

  • drmike

    I'm trying to come up with a different method at the moment, but am not 100% sure how practical it will work.

    My understanding of how the version used to work (it got explained in very basic terms once in the support forums) is their version tries to detect if the mapped domain cookie is present. If yes, all is good. If not, it then tries to detect if the main cookie is present. If it;s not, the process ends as the user is not logged in. If the main site cookie is detected, then a cookie is served for the mapped domain. Going off memory though.

    They used to use some weird 30 minute process way back when that had issues. If you search the forums for 37 strikes or 37 pitches or whatever that blog is called, you should find about a dozen threads where folks were complaining about how after creating an account, folks still couldn;t create comments. They went away after a while so they muct have changed something.

  • exberry

    I will revive this old thread. I am using Domain Mapping 3.0 with WP3.01 and BP.

    When I domain map a sub-folder, the mapping works OK but the cross-domain login gets killed.

    I have played with this enough to confirm it is repeatable, even after clearing browser history.

    The strange thing is this problem did not occur last week, only this week.

    Are there any new solutions to this problem since the last comment in this thread?



  • Denis Lam

    I just discovered I have a cookie issue... Domain mapping works no problem with my WPMU subdomain set up however I have to login again when I go to that mapped domain.

    In my wp-config, I have these set up:

    define('WP_ALLOW_MULTISITE', true);
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL', true);
    define('DOMAIN_CURRENT_SITE', '');
    //define('PATH_CURRENT_SITE', '/');
    //define('SITE_ID_CURRENT_SITE', 1);
    //define('BLOG_ID_CURRENT_SITE', 1);
    define( 'NOBLOGREDIRECT', '' );

    Is there something I need to change?

  • Mitch

    Sorry to revive an old thread, but has any progress been made on this issue? I just purchased this plugin completely because of this sentence on the main plugin page, "Cross domain syncing is built in, so your users will stay logged in (or out) regardless of whether they are on your standard domain or their own custom one." But it's not doing what I expected...

    I still run into the same issue that others are having whereas I can login to my mapped subdomain and get logged into my main domain too, but when logging into my main domain I don't get logged into my mapped subdomain.

    If a solution has not been found for this, I'd like a refund for the purchase I made about 30 minutes ago based on what I believe to be false-advertising. (You guys even noticed how misleading it was in an above post but seem to have chose not to do anything to make it more clear...) Otherwise, this is a very nice plugin. Thanks! :slight_smile:

  • DavidM

    Hi guys,

    Thanks for your feedback and thoughts on this. As this thread is a bit old now, there are other threads, like the following, that have more up to date details on all this:

    @Mitch, we've received your email and will respond shortly. Just wanted to mention this quickly here. :slight_smile:


Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.