search

froger-me / wp-remote-users-sync

Synchronise users across WordPress websites
GNU General Public License v3.0
72 stars 33 forks source link

Best practices with WPML #13

Closed mennobouma closed 4 years ago

mennobouma commented 4 years ago

[From Wordpress.org]

-- Hello Alexandre,

I’m using your plugin with WPML, with one language per domain. I would like to know what the best practices are, do i need to add all languages as remote sites or only the main site and use the SSO feature of WPML?

I did some testing on this:

Adding the WP install language only doesn't login the other translated domains. Adding the WP install AND translated domain does login both languages / sites.

So i need to add a remote site for every language. But the logout doesn't work. Please test it with these sites, both run 1.2.7-dev:

https://www.lifecloud.id/ English - WP install https://www.lifecloud.nl/ Dutch - Translation

https://www.lifegroup.nl/my-account/ English - WP install https://www.lifegroep.nl/mijn-account Dutch - Translation

[Credentials removed by @froger-me]

The SSO feature of WPML doesn't work too at this moment even when it's enabled in the admin. https://wpml.org/documentation/getting-started-guide/language-setup/passing-session-data-between-languages-in-domains/.

I think the best scenario is that only the WP installs (English sites) need to be added as remote sites and not the languages (other domains). When you login or logout in needs to work on the wp install and the translated domains.

I don't know for sure if a part of the issue is with your plugin or with WPML. Or a combination :).

Thanks, Menno

froger-me commented 4 years ago

Hi Menno,

Which browser are you testing with? I am gonna speculate here, but it appears from the WPML source code that Safari and browsers with cross-domain cookie disabled won't allow WPML SSO, because they use iframes. Same issue as I originally encountered with WPRUS.

It looks like that for the WPML SSO to work in all browsers (which, again, I haven't used before, so I'm not sure, and not 100% familiar with WPML inner code), that would be with subdomains only, provided the cookie domain WordPress constant COOKIE_DOMAIN is set to the top level domain.

froger-me commented 4 years ago

Other question: is WPML SSO working without WPRUS activated?

I did see the WPML SSO call upon login on https://www.lifecloud.id ( call to https://www.lifecloud.nl/?wpml_sso_iframe_hash=[some_hash] in the iframe) but didn't get authenticated on https://www.lifecloud.nl...

Also, WPRUS does authenticate the user on https://www.lifegroup.nl/my-account/ , but not on https://www.lifegroep.nl/mijn-account, as you mentioned. Looking at the network inspector though, WPML SSO https://www.lifegroep.nl/?wpml_sso_iframe_hash=[some_hash] does get called properly upon visiting https://www.lifegroup.nl/my-account/ - so, same issue as above.

So this question is very relevant, we might be onto something. Could be WPRUS interfering, could be pre-existing misconfiguration muddying the waters.

Oh, and the feature you linked to does not do the WPML SSO per se, it simply passes cookie and session data across domains (if you meant the "Pass session arguments between domains through the language switcher" option which is the focus of the article). What matters in our case is the option above it ("Auto sign-in and sign-out users from all domains").

mennobouma commented 4 years ago

Hello Alexandre,

Thanks for your reply. I'm testing with Google Chrome on desktop.

I was able to login WPML on all domains by adding this to wp-config.php:

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

But it looks like it's not working with your plugin.. Does www.lifecloud.id works at your place?

Thanks, Menno

froger-me commented 4 years ago

Hi Menno,

At the time of writing, logging in on https://www.lifecloud.id does not log me in anywhere else ; this is a different behavior from the previous test, and I cannot know what settings changed (or what the totality of the settings of WPML and WPRUS across the websites are), which makes it difficult for me to draw any conclusion.

Could you first disable WPRUS and activate the WPML SSO for all languages? My plan would be to test in different browsers to see what happens, to isolate and understand the initial behaviors, and then work out a WPRUS configuration based on that.

froger-me commented 4 years ago

Testing further before your last comment and changes of settings ; when logging in https://www.lifecloud.id/, I got logged in the registered websites in WPRUS:

I do not know if that's all the sites that were registered in WPRUS, but if it was, then the WPRUS SSO was working as designed.

After more research, here is the deal when combining WPML SSO and WPRUS SSO.

Let's take the example below:

Here is what would happen upon login:

So, https://www.lifegroep.nl couldn't set its authentication cookie ; the domain it depends on, https://www.lifegroup.nl/, had only a minimal WPRUS SSO page loaded in an iframe that didn't itself load the WPML SSO iframe.

Working around that would mean loading the full https://www.lifegroup.nl/ page (or at least the WMPL output) in the WPRUS SSO iframe to allow for the WPML SSO https://www.lifegroep.nl iframe to load within it ; it would result in a nested iframe which would cause its own array of issues, possibly conflict with themes, and serious performances degradations (breaking server redirects, only relying on javascript redirection, that would have to be done only after the iframes are loaded - all that adds up veeeeery fast).

And if we now establish Safari does exist: iframes auth cookies would not work, so we can forget about WPML SSO in Safari - I dug in the WPML code more, and I'm 99% confident it's not supported by WPML ; and even if it was, it would mean more redirects 🙁.

That's a technical limitation, not really an algorithmic issue.

What now?

A WPRUS setup I can see working, with Login action active in both directions:

This way:

Untested, but feasible within the technical limitations of how WPML, WPRUS, SSO, browsers and the Internet in general works. Horrible performances and UX in Safari/iOS.

Please note that this sort of cross-browser, cross-domain, multilingual, no-user-intervention SSO, with more than 3 websites is the sort of challenge even big brands such as Stackexchange still struggle with (Stackexchange's SSO does not work in Safari, for instance), and a free plugin like WPRUS in unlikely to be able to compete with such powerhouses.

mennobouma commented 4 years ago

Hello Alexandre,

Thanks for your extensive research!

When i add this:

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

WPML works but your plugin not. I just removed it. Now your plugin should work after restart of your browser.

Your WPRUS setup looks interesting. I can e-mail you FTP and admin logins if you want. It's ok to test things at lifecloud.id and lifegroup.nl.

I understand it's quite complex to build this with a (free) plugin. Maybe it's possible to use the REST API to build bridges between multiple WP sites. Just some thoughts :).

froger-me commented 4 years ago

Hi Menno!

The issue is, no matters how the server is reached, it needs to set an authentication cookie in the user's browser.

This is done in only 2 ways:

Anything else regarding how it's done (REST, WPML's own brand of SSO, WPRUS's API, redirections, etc) is just decoration as far as how the Internet inner workings are concerned.

Similarly, changing cookie constants in WordPress can only affect the domain and subdomains where these constants sit: it is not possible to allow a server pointed by one domain to set a cookie for another domain.

These technical limitations are here for security, and it's a layer hard coded in browsers. Without this, any malicious server could hijack authentication on any website (including the most sensitive ones such as banking).

I'm going to close the issue. The suggested settings are not recommended, but simply an effort to find what is technically possible. Would you wish I spend more time experimenting with your setup, we can discuss a fee for that, but because I don't think it's viable from a user standpoint and because I think you'd actually be able to tinker with the settings yourself, I'd feel like I'd be robbing you 😉.

mennobouma commented 4 years ago

Hello Alexandre,

I think i'm going to bring all languages to the primary domain, so it's going to be www.lifecloud.id/nl etc. Then your plugin features work on all languages.

froger-me commented 4 years ago

Indeed, that would work - using subdomains too (in which case you could make use of the WordPress cookie constants) is possible, like https://nl.lifecloud.id and the like. Having a top domain per language is in certain cases an advantage regarding branding localization (like we see with https://www.lifegroep.nl), but if you can get away without it, it makes the technical side of things much more workable.