humanmade / Mercator

WordPress multisite domain mapping for the modern era.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to login if single sign-on is disabled

aussieveen opened this issue · comments

Whenever I disable the single sign on through the filter

add_filter( 'mercator.sso.enabled', '__return_false' );

I tracked down the cause of this to be the fact that the COOKIE_DOMAIN isn't defined as including something like

$dm_domain = $_SERVER[ 'HTTP_HOST' ];
define( 'COOKIE_DOMAIN', $dm_domain );

allows it to work again.

I think this is related - 0aa1048

+1 for this.

Also it's not really clear where the filter needs to be loaded in order to be recoginzed. I tried running it in different places, muplugins_loaded, plugins_loaded, mercator_load all with no effect. I wound up manually disabling it within Mercator itself and then ran into this issue.

Running that filter right before line with require WPMU_PLUGIN_DIR . '/mercator/mercator.php'; in sunrise.php works for me.

I was also having this issue. When trying to log in with an aliased domain, cookie domain is incorrect. I think probably Mercator\SSO\initialize_cookie_domain needs to run whether SSO is disabled or not - currently it will not load if sso is disabled.

My current work around is the following sunrise file:

<?php

// Default mu-plugins directory if you haven't set it
defined( 'WPMU_PLUGIN_DIR' ) or define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR . '/mu-plugins' );

add_filter( 'mercator.sso.enabled', '__return_false' );
add_action( 'muplugins_loaded', 'Mercator\\SSO\\initialize_cookie_domain' );

require WPMU_PLUGIN_DIR . '/mercator/mercator.php';

@humanmade any response here? seems like we shouldn't have to hack mercator to get it to work right. is there not a simple fix for this?

Sounds like we need to fix it :)

@rmccue I've been working on some fixes to the plugin. I'm assuming you would be ok with me sending some pull requests? I have one ready that fixes the "get_stylesheet_directory_uri()" and similar functions. I also figured out why people are having this SSO issue. Its because we are changing the "site_url" which after reading the code I realize thats not intended. I think we need to update some documentation too, to indicate the proper way to add subsites and convert them to TLDs. I'm stuck on fixing the URLs in the MySites nav, but I'll create separate issues and work them out as I move through the plugin (as long as your ok with my contributions). I'm really hoping @fansided can start using this plugin moving forward for SSO but I need it to be production ready!

@simonmcwhinnie @robneu I've tested the code from @cmmarslender and it works as expected. Make sure you delete all your previous cookies, or change your wp-config salts to wipe out previous sessions, and then SSO will be disabled with the filter and action from above.

@rmccue I think we just need to add this to the documentation on how to disable SSO (though I'm hoping less people will do this once we fix the issues related to having SSO enabled). Also, thoughts on moving disabling SSO to a network option page? I could build this if its desirable.

I think we can close this issue.

Reasoning for disabling SSO wasn't so much that it wasn't working (it was working, when it was enabled) - but more about the fact that there seemed to be a blocking request to admin-ajax every page load for logged out users - Understand why, but that wasn't desirable for performance reasons (both client side and server load).

To me, seems like initialize_cookie_domain should be called whether SSO is enabled or not, rather than just documenting my current workaround.

To me, seems like initialize_cookie_domain should be called whether SSO is enabled or not, rather than just documenting my current workaround.

I agree; we should move this out of SSO and into the main Mercator file, and always hook it in.

This happened to me yesterday and I was tearing air out. I fixed it by making the site URL subsite.networkdomain.com and adding an alias for newdomain.com - instead of having the opposite (newdomain.com as the site URL and subsite.networkdomain.com as an alias), because the test cookie was always showing ".networkdomain.com" as the domain. (Then I changed my salts and emptied caches.)

Out of interest, what is the recommended was of setting up this plugin. There are no instructions provided.

Yes, that kind of works, until you notice the wp-admin bar dropdown of sites having wrong URL's which causes the links to fail / redirect you to a login page with &reauth=1.\

How it was intended to be setup, well, thats on @rmccue I'm not 100% sure.

Apologies for not following this thread correctly - I didn't pick up on the fact that SSO is disabled via sunrise.php - I was messing with Jetpack SSO; an entirely different thing it would seem. I have added the workaround in sunrise.php and am seeing faster page load times. +1 for building this in.

@scarstens so far, fingers crossed and touching wood, I haven't noticed the rogue URL effects in wp-admin bar that you described. I did replace salts and clean all caches (memcache, nginx fastcgi, pagespeed) - so far so good.

It would be nice for my sites to have their site URL as the main domain though. Not sure what else will be affected by doing the opposite.

@robrecord have you tried navigation between your sites using the wp-admin bar dropdown? this is where the problem starts.

It appears to work for me, after first logging in to network.com/wp-admin

The sites in the dropdown all have subdomain URLs, but it works okay and doesn't ask me to log in again. which is surprising as I thought I had disabled SSO in sunrise.php.. or maybe I'm doing it wrong.

Would be keen to find any bugs ahead of time so if there's some refinement I should make in order to see the bug, please let me know. Thanks

Rob

http://robrecord.com | +44 (0) 7535 271 502

On 26 Feb 2016, at 16:26, Seth Carstens notifications@github.com wrote:

@robrecord https://github.com/robrecord have you tried navigation between your sites using the wp-admin bar dropdown? this is where the problem starts.


Reply to this email directly or view it on GitHub #48 (comment).

@robrecord whenever youtube decides to encode my video, this demo should show you the problem I'm having with WordPress reauth filter vs mercator

https://www.youtube.com/watch?v=9fN5Q7ZixQQ

Ok yes I'm seeing the same issue.

Another workaround is to set the primary domain as the site URL, and have the subdomain as an alias. If you then add another alias with WWW in front, you can sign in by accessing the website using the WWW alias.

This isn't great for my clients who have to remember to do this.

Would really like to get this fixed. Is there any way I can help?

I had the same Issue when using add_filter( 'mercator.sso.enabled', '__return_false' ); and i fixed it by adding the following.

add_action( 'muplugins_loaded', function () {
	if ( defined( 'COOKIE_DOMAIN' ) ) {
		return;
	}

	$current_site = $GLOBALS['current_blog'];
	$real_domain  = $current_site->domain;
	$domain       = $_SERVER['HTTP_HOST'];

	if ( $domain === $real_domain ) {
		$cookie_domain = $real_domain;
		if ( 'www.' === substr( $cookie_domain, 0, 4 ) ) {
			$cookie_domain = substr( $cookie_domain, 4 );
		}

		define( 'COOKIE_DOMAIN', $cookie_domain );
	}
} );

Basically doing the same thing Mercator\SSO\initialize_cookie_domain would do but not bailing if it is not in a mapped (so that it works for the primary domain).
There is no $GLOBALS['mercator_current_mapping'], because Mercator\register_mapped_filters bails out if it is the primary domain in the site URL.

(Actually just noticed the dates and not sure if this issue is still completely relevant, but I'm going to say yes, since I just had this issue^^)

Definitely appears to still be a problem.

I got this error message,

The constant COOKIE_DOMAIN is defined (probably in wp-config.php). Please remove or comment out that define() line.

"COOKIE_DOMAIN" constatnt is important for wpmudev domain mapping
because I am using multi network plugin, need to enable two domain mapping system

@masterseoonline COOKIE_DOMAIN will be set automatically during the domain mapping process, you do not need to set it manually in your config.