• Plugins
  • Created On ,
  • Most Recent By DavidM,

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
    • 19
    • #5867

    I went through the entire thread, but didn't find anything to fix my problem. Can you be specific?

    Barry

    Have you got any of the following defines in your wp-config.php?

    COOKIE_DOMAIN, DOMAIN_CURRENT_SITE or BLOGID_CURRENT_SITE if so can you comment them out.

    Nathan Barry
    • 19
    • #5867

    I have both DOMAIN_CURRENT_SITE and BLOGID_CURRENT_SITE.

    I commented those out, but the cross domain login still doesn't work. Any more ideas?

    Barry

    Can you have a look at what is being loaded in the header of one of your admin pages (when logged in on the mapped domain). If possible use firefox and firebugs net tag, which will show the pages that aren't loading in red.

    And if poss, post your config file here (but with the passwords and AUTH_KEY / Has fields removed / blanked out.

    Nathan Barry
    • 19
    • #5867

    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:

    -------------------------

    <?php
    /**
    * 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', 'shop208beta.com' );
    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 https://api.wordpress.org/secret-key/1.1/ WordPress.org 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
    * de.mo 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 http://examples.com/ for the following: define( 'NOBLOGREDIRECT', 'http://example.com/' );
    // 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
    • 19
    • #5867

    Any ideas for making this work?

    This site is supposed to go live tomorrow.

    I appreciate the help!

    Barry

    I would try commenting these two lines out as well to be sure:
    define('PATH_CURRENT_SITE', '/' );
    define('SITE_ID_CURRENT_SITE', 1);

    Then, clear all the cookies on your main domain and the mapped one. Log in to the mapped domain and have a look at the cookies that start with wordpress to see what domains it has created cookie for.

    Nathan Barry
    • 19
    • #5867

    I commented out those two lines.

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

    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.

    Does that help?

    Barry

    Just to go over what we have so far:
    You have sub.domain.com and it's mapped domain subdomain.com

    if you log into subdomain.com then it creates the cookies for domain.com (and thus sub.domain.com)

    if you log into sub.domain.com it doesn't create the cookies for subdomain.com?

    You have a single domain mapped to sub.domain.com?

    Nathan Barry
    • 19
    • #5867

    Yes that sounds right.

    I have subdomain1.com mapped to the blog sub1.primarydomain.com & subdomain2.com mapped to sub2.primarydomain.com (only one domain mapped to each blog). Then I have primarydomain.com.

    If I log into subdomain1.com it creates cookies for itself and for primarydomain.com, but not subdomain2.com.

    If I log into primarydomain.com 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.

    Thanks!

    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?

    Nathan Barry
    • 19
    • #5867

    Seeing this on the marketing site made me think that the plugin was more robust:

    And, naturally, we've built in cross domain cookie syncing, so your users will stay logged in (or out) regardless of whether they are on your standard domain or their custom one.

    It definitely sounds like if you login to one mapped domain, you will be logged into ALL mapped domains on the MU installation.

    James Farmer
    • Staff
    • 885
    • #90

    Hmmm... I think it is a feature, but I'm not 100%... it certainly *should* be a feature :)

    Will look into it more...

    Apologies for any confusion.

    Nathan Barry
    • 19
    • #5867

    Well, I appreciate you guys looking into it more.

    Barry

    It should work like this:

    sub.domain.com -> mysub.com

    These are the orig domains and the mapped domains.

    If I log into sub.domain.com it will automatically create the cookies for mysub.com
    If I log into mysub.com it will automatically create the cookies for sub.domain.com

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

    Nathan Barry
    • 19
    • #5867

    It seems as though this is quite a bit more basic than advertised. Are there plans to build the robust cross-domain login plugin mentioned on your marketing page?

    James Farmer
    • Staff
    • 885
    • #90

    Not sure I agree with you there Nathan, although we'll certainly consider any extra features you;d like to see, just put in a quick description and we'll discuss them with other members and check out interest.

    Nathan Barry
    • 19
    • #5867

    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?

    • 0
    • #0

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

    mu Install = MUInstallDomain.com
    User Install = user.MuInstallDomain.com
    User Install Mapped = UserInstallMapped.com

    Our users are, for the most part, no matter how many times we tell them otherwise, logging into their dashboards from our MUInstallDomain.com Which, even if they have a mapped domain, auto-forwards them to their user.MuInstallDomain.com 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 MuInstallDomain.com sends them.

    Even if MuInstallDomain.com 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 sub.domain.com - logs user into sub.domain.com, domain.com, mappeddomain.com

    Log in to mappeddomain.com - logs into mappeddomain.com, sub.domain.com, domain.com

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

    If a user logs into domain.com, then they are also logged into sub.domain.com, but not mappeddomain.com - 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.

    Nathan Barry
    • 19
    • #5867

    How much overhead is it to check, when the user visits mappeddomain1.com if they are already logged in to domain.com and if so automatically log them in to mappeddomain1.com.

    This way you could simulate the behavior of being logged into all mapped domains when you login to one, but without having to create all those cookies every time.

    • 0
    • #0

    @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.

    @Nathan
    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 mappeddomain1.com we can't read the cookies for domain.com 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.com 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.

    Nathan Barry
    • 19
    • #5867

    Has there been more thought on enhancing this plugin? That would make it very powerful!

    Andrew
    • Erstwhile founder
    • 7,430
    • #14

    At the moment we're busy preparing other plugins for launch. We'll revisit this plugin shortly.

    Thanks,
    Andrew

    outolumo
    • 3
    • #19959

    How about asking from the main site if user is logged there (has the appropriate cookies)? Is it possible to use some kind of redirection for that?

    Namely this is a feature I would very much like to see:

    Login to any hosted domain - Single Sign On to all of them.
    Logout from any - Single Logoff from all of them,

    DocValerian
    • 1
    • #27985

    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)

    Andrew
    • Erstwhile founder
    • 7,430
    • #14

    Hiya,

    Barry (plugin developer) will get back to you on this as soon as possible :)

    Thanks,
    Andrew

    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 wp.com 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 wp.com 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.

    DocValerian
    • 1
    • #27985

    Hey there,

    thanks a lot for the fast response on my q. (the support here really IS superb) I'll try looking into it these days.

    greetings from Berlin

    Barry

    @drmike - thanks for the idea - I've had a hunt around WP.com forums but couldn't find anything, however I did find some people using the wp.com domain mapping, so I've had a look at their sites to see what's going on behind the scenes...

    Looks like my new approach was on a similar track, so I shall push ahead with it.

    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?

    Thanks,

    Ed

    Denis Lam
    • Elite
    • 359
    • #230

    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', 'xxx.com');
    //define('PATH_CURRENT_SITE', '/');
    //define('SITE_ID_CURRENT_SITE', 1);
    //define('BLOG_ID_CURRENT_SITE', 1);
    define( 'NOBLOGREDIRECT', 'http://xxx.com' );

    Is there something I need to change?

    Mitch
    • 4
    • #17452

    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! :)