Switch from WPMU Domain Mapping to Mercator
We currently use the WPMU Domain Mapping plugin to provide mapped domains, however that plugin doesn't get many updates and the code quality could be improved.
Mercator is Human Made's alternative to domain mapping and has better support for object caching and SSO.
This also gives us a chance to stop redirecting logged-in users to the Commons subdomain (#5525). We did this to ensure login requests and the admin dashboard are served over HTTPS. However, since IT has implemented Let's Encrypt, we no longer need to do this.
I'm targetting this for 1.18.
#3 Updated by Raymond Hoh over 1 year ago
Mercator is now available for testing on cdev.The biggest user-facing changes are:
- We no longer redirect mapped domains back to the Commons subdomain when attempting to go to the site's admin dashboard.
- Single sign-on (SSO) now works if you attempt to login from a mapped domain. Or if you are logged into the Commons and then attempt to navigate to a mapped domain.
For super administrators, mapped domain administration now takes place at "Network Admin > Sites > All Sites" and clicking on the individual site, followed by the new "Aliases" tab to add or remove a domain.
To those that want to test SSO with a mapped domain on cdev, you'll need to adjust the HOSTS file on your computer with the following:
184.108.40.206 commons.gc.cuny.edu taliaschaffer.commons.gc.cuny.edu taliaschaffer.com
With the HOSTS file change applied, next:
1. Login at commons.gc.cuny.edu
2. Navigate to
3. You should notice a brief delay, followed by a redirect, and then you should be logged in at
If you are not logged into
taliaschaffer.com, you might have blocked third-party cookies in your browser. If that is the case, add a cookie exception for
commons.gc.cuny.edu in your browser and reload the page.
If you log out from taliaschaffer.com via the WP toolbar, you will also be logged out of the Commons as well.
I've also tested other iterations like logging in from
taliaschaffer.com/wp-admin first and I was able to login successfully.
To accomplish this, technically, there were a few hoops I had to jump through.
(This is mostly for Boone and Jeremy. However if you're not interested, you can stop reading!)
1. Cross-domain SSO requires cookies to set some additional parameters
For relatively newer browsers, in order for SSO to take place across different domains, some additional parameters need to be set for WP's auth cookies. Namely
None and since our site is served over HTTPS, the
Secure flag also needs to be set.
More info can be found here: https://itnext.io/user-agent-sniffing-only-way-to-deal-with-upcoming-samesite-cookie-changes-6f79a18e541#b2d9
One problem with setting these cookie flags is older browsers will not read these flags correctly. This most likely means that SSO will not work in these cases. The article I linked to above lists the affected browsers:
- Any browser on iOS 12. This affects the following devices: iPhone 5S, iPhone 6/6 Plus and iPod Touch (6th gen).
- Safari on MacOS 10.14.
- Chrome 51–66.
- UC Browser < 12.13.2 for Android
I don't think this is a major issue, but if it is, a workaround would be to do some user-agent sniffing for the browsers listed before setting the cookies. I also haven't tested any of these older versions, but if it is important, I can do so.
2. Mercator patches
There are several patches that I've sent upstream to the main Mercator plugin. I'll list some of the main ones below and what they address:
- Use the current session token when setting the auth cookies. Sharing the current WP session for SSO fixes an issue with being constantly logged-in when attempting to log out from a mapped domain.
- Introduce a redirect filter after SSO is completed. Due to the way we use a custom login template that loads the current site theme's template on the login page (#3780), if SSO is in the process of completing, we can just use the login page's
redirect_toURL instead of looping back to the login page again. I'm using this filter here.
And a few patches that I haven't sent upstream:
admin-ajax.phpand does some redirections, so the load time will take a bit longer than usual. Basically, moving to async helps to speed up the pageload time when on a mapped domain for visitors that are not apart of the Commons.
- Add redirect module. Mercator has a separate module housed at a different Github repository for redirecting subdomains to mapped domains. I just moved the code into the
mercatordirectory for better management.
3. Removal of older subdomain / HTTPS workarounds
I've mostly undone the work from #3587, #3890 and #5525 because HTTPS is now enforced on the Commons unlike before when we had a mix of HTTP and HTTPS assets. There are probably some other parts of the codebase that can benefit from a HTTPS audit, but for now, we're good.
I've also tested other things that might affect Mercator such as the upcoming two-factor feature and they work together well.
If anyone notices any problems on cdev, please let me know.
#4 Updated by Boone Gorges over 1 year ago
Thank you so much for working through this! I have been reading through your commits and PRs and also testing on cdev and I am pleased and impressed with the thorough and careful approach to the swap-out.
I have a question about redirect_to behavior. I tested the following:
1. Type https://taliaschaffer.com/wp-admin/users.php into a browser
2. I'm led to https://commons.gc.cuny.edu/wp-login.php?redirect_to=https%3A%2F%2Ftaliaschaffer.com%2Fwp-admin%2Fusers.php
3. After entering credentials and clicking Log In, I'm led back to the same wp-login.php URL after some redirects. In the network tab, I see the following chain of requests:
- POST https://commons.gc.cuny.edu/wp-login.php (this is the initial login request, which seems right)
- 302 to https://taliaschaffer.com/wp-admin/users.php (this appears to be the correct behavior of wp-login.php's redirect_to parameter)
- 302 to https://taliaschaffer.com/wp-login.php?redirect_to=https%3A%2F%2Ftaliaschaffer.com%2Fwp-admin%2Fusers.php&reauth=1 This is the part that seems incorrect. I'm guessing that the asynchronous SSO for taliaschaffer.com isn't completing before the wp-admin page loads.
- 302 to https://commons.gc.cuny.edu/wp-login.php?redirect_to=https%3A%2F%2Ftaliaschaffer.com%2Fwp-admin%2Fusers.php - is this the default Mercator behavior, to redirect logins through the main site?
This kind of flow feels important for two reasons. One is that admin notification emails - say, comment approval - will contain wp-admin links that should be properly redirected.
The other is that a future integration with CUNY's SSO may depend on this redirect behavior. There are many details to work out on that end, but I assume that part of the process will be for the IDP to send identity headers back to a central URL - maybe commons.gc.cuny.edu/wp-login.php? - from which point we will redirect to the originally requested URL.
#5 Updated by Raymond Hoh over 1 year ago
Thanks for testing, Boone.
I have a question about redirect_to behavior.
I thought I tested navigating directly to a mapped domain's admin URL when logged out, but I might have tested when I disabled the redirect to the main site to login.
Anyway, your bug is valid and I've worked around this by changing the login URL redirect.
Now, this is how the redirection works:
1. Go to
2. This takes you to the main site's login page -
What's happening here is I changed the
redirect_to parameter here from
3. After login, you get redirected to the mapped domain's frontend where Mercator's async SSO kicks in and you should be logged into the mapped domain.
4. Now, the final redirect occurs from the frontend's
redirect_to and should take you to
This is available for testing on cdev. (Commit - https://github.com/cuny-academic-commons/cac/commit/e7b64fc248d5e602cd0d1f8a4eed0acc6a5ca325)
I believe this workflow will work with CUNY SSO. We just have to make sure we forward any mapped domain admin URLs first to the frontend and later back to the admin area.