CUNY Academic Commons

Thanks so much for working on this, Boone -- I really appreciate it.

On another site, I did write a code snippet for this.

• Change the login URL if on a mapped domain to use the main site's login.
• See if a login redirect is using a mapped domain. If so, we switch out the mapped domain with the original subdomain in the login redirect.
• Redirects subdomain requests to their mapped domain equivalent.
• Redirects logout requests from a mapped domain to the main site. This ensures that cookes are cleared on both the subdomain and the mapped domain.

FWIW, these are the WPMU Domain Mapping settings that are used on the site:

The "Remote Login" option in WPMU Domain Mapping should be disabled when using this snippet. I believe the permanent redirect one should be as well.

Thank you, Ray! I'm glad I asked - it looks like this code has been through a couple of rounds of QA :)

You have any suggestions about how best to test this for the Commons? Should we map a domain or two to cdev?

it looks like this code has been through a couple of rounds of QA :)

Yeah, we were testing with both Mercator and WPMU Domain Mapping, hence the revision count!

Should we map a domain or two to cdev?

I think that's probably the best thing to do to avoid testing on production.

I've got a couple of free domains not in use.

So to move forward, commit my code to 1.13 branch and create a dummy site on cdev. Next, update WPMU Domain Mapping's settings to map the sub-site's subdomain to the domain.

And lastly for the DNS, map to the cdev IP instead of the production IP?

Yup, that all sounds right to me - and I think if you use a CNAME, you won't need Lihua to make any Apache-level config changes.

To add one more thing to the checklist: let's be sure that we are doing some redirect magic when someone tries to access mappeddomain.com/wp-admin or mappeddomain.com/wp-login.php directly. There may be people who have bookmarks to deep links, and we don't want to leave them in the dark. The plugin probably already does this, but I wanted to flag it.

Boone, are you able to use cdev with subdomain URLs?

To test, I tried adding the cdev IP to my HOSTS files with the dev.commons.gc.cuny.edu subdomain and I'm getting the following error in Firefox:

dev.commons.gc.cuny.edu uses an invalid security certificate.

The certificate is only valid for the following names: *.gc.cuny.edu, gc.cuny.edu
Error code: SSL_ERROR_BAD_CERT_DOMAIN

Temporarily allowing this shows a generic Apache test page. Does Lihua need to do something to configure cdev to work correctly with our wildcard subdomains?

I'm seeing the same thing. Let me check with Lihua.

Now that SSL is working for subdomains on cdev, I've added a mu-plugin called wp-ms-login.php to cdev for testing.

For the mapped domain test, I'm currently testing with the existing sexgenlab.org domain by adding the following entry into my HOSTS file:

100.00.00.00 sexgenlab.org sexgenlab.commons.gc.cuny.edu (replace 100.00.00.00 with cdev's IP).

There are some caveats with testing on cdev:
- You'll need to confirm some security exceptions in your browser, due to the HOSTS change
- The dual login code to ensure you are logged in to the mapped domain relies on a javascript file that is blocked if you use Adblock Plus or uBlock Origin with the EasyPrivacy filter list in your web browser of choice. If you run into problems not being logged in, check your adblocking extension and temporarily disable it on the commons.gc.cuny.edu domain.

On cdev, I also changed the WPMU Domain Mapping settings to the picture I added in comment 2. (The previous settings had "Permanent redirect" checked and the rest unchecked.)

Boone, once you've had a chance to test things, let me know what you think.

Thank you for your work on this, Ray! Mostly it's looking good.

Can you have a look at the <form> on the admin bar login form? It appears to be directing toward the mapped domain sexgenlab.org, when it should be pointing to sexgenlab.commons.gc.cuny.edu. This is breaking things a bit; attempts to login via the form are being 302ed toward commons.gc.cuny.edu/wp-login.php, which means that the user has to log in again.

The login flow seems to work properly when going from commons.gc.cuny.edu/wp-login.php?redirect_to=https://sexgenlab.commons.gc.cuny.edu; I assume that it's the interim visit to sexgenlab.commons that's triggering sexgenlab.org auth cookie, because when I finally end up on sexgenlab.org, I'm logged in. But when I log in at commons.gc.cuny.edu in the normal way, and then navigate to sexgenlab.org, I'm not logged in. I guess I'm not surprised that this doesn't happen automatically - it would be kinda crazy to log you into every mapped domain on the system - but I wonder if there's something we can do to detect this a bit more gracefully. Not a deal-breaker, but more a question for discussion.

Log out seems to work properly in both directions.

Can you have a look at the <form> on the admin bar login form? It appears to be directing toward the mapped domain sexgenlab.org, when it should be pointing to sexgenlab.commons.gc.cuny.edu. This is breaking things a bit; attempts to login via the form are being 302ed toward commons.gc.cuny.edu/wp-login.php, which means that the user has to log in again.

Should be fixed on cdev now.

the mapped domain relies on a javascript file that is blocked if you use Adblock Plus or uBlock Origin with the EasyPrivacy filter list in your web browser of choice. If you run into problems not being logged in, check your adblocking extension and temporarily disable it on the commons.gc.cuny.edu domain.

If you're interested in the rule that is blocking this functionality, I've filed a report to the EasyPrivacy list maintainers - https://github.com/easylist/easylist/issues/948

For now, I'm working around the EasyPrivacy filter list by copying and pasting WPMU Domain Mapping's code and changing the dm parameter to cacdm.

The login flow seems to work properly when going from commons.gc.cuny.edu/wp-login.php?redirect_to=https://sexgenlab.commons.gc.cuny.edu; I assume that it's the interim visit to sexgenlab.commons that's triggering sexgenlab.org auth cookie

Correct!

But when I log in at commons.gc.cuny.edu in the normal way, and then navigate to sexgenlab.org, I'm not logged in.

Yeah, it's not really possible to do this with the WPMU Domain Mapping plugin unfortunately.

it would be kinda crazy to log you into every mapped domain on the system - but I wonder if there's something we can do to detect this a bit more gracefully. Not a deal-breaker, but more a question for discussion.

As crazy as it sounds, I did come across another plugin that does log you in to every mapped domain - https://wordpress.org/plugins/wp-multisite-sso/

I'm not sure if it will work for us, but we could give it a try on cdev. It uses JSONP requests, which I'm not sure if we support:
https://github.com/voceconnect/wp-multisite-sso/wiki

Also looks like there is an issue with authenticating over HTTPS, which we'll need to fix for our needs:
https://github.com/voceconnect/wp-multisite-sso/pull/15

I'm so glad you guys are addressing this -- I've found it strange not to be able to see the dashboard of mapped domains that I know are hosted on the Commons. thank you.

A brief follow-up from Tuesday's meeting: Ray's going to look into whether the wp-multisite-sso plugin can be modified so that users are only logged into mapped domains where they have a WP role. This will be less than 100% seamless for super admins, since super admins are able to visit the Dashboard of sites where they have no role. Matt, once this is implemented, you'll probably want to be sure that you have a role on any mapped domain that you regularly visit, to help minimize the strangeness you describe above.

Okay -- thanks, Boone. I guess that would mean that I would have to contact site owners and ask to be added, unless we were to do that without owner approval?

Correct.

Note that you'll always have the workaround of simply logging in, using your Commons credentials, to mapped domains. You can even do this now, as a super admin. It's just not automatic.

I've done some testing and modifications to the wp-multisite-sso plugin.

Logging in to mapped domains work. But there's a big caveat.

Your browser needs to accept 3rd-party cookies. Most browsers, by default, are set to allow 3rd-party cookies, but if you have explicitly blocked 3rd-party cookies for privacy reasons, you'll need to either change this browser setting, or you'll need to add cookie exemptions for each of your mapped domains.

If 3rd-party cookies are blocked, you can still log in manually when you visit a mapped domain though, so it's kind of like our current behavior.

If you want to test on cdev, for your user account that you'll be logging in with, you'll need to add a role to each site with a mapped domain:
https://commons.gc.cuny.edu/wp-admin/network/settings.php?page=dm_domains_admin

You'll also need to make a change to your computer's HOSTS file as noted in comment 11 for both the subdomain and the mapped domain.

FWIW, Boone, I've submitted changes to the wp-multisite-sso plugin here. And the filter I'm using can be found in wp-content/mu-plugins/wp-ms-login.php, located at the very bottom.

I also think I'm going to remove the WPMU Domain Mapping login code I previously wrote since it's hacky and I don't like using javascript redirects to set cookies. The wp-multisite-sso plugin is working quite well, apart from the caveat about 3rd-party cookies I noted above.

Boone Gorges wrote:

Correct.

Note that you'll always have the workaround of simply logging in, using your Commons credentials, to mapped domains. You can even do this now, as a super admin. It's just not automatic.

Does that mean that I replace the mapped domain (e.g. mattswebsite.org) with the commons URL (e.g. mattswebsite.commons.gc.cuny.edu)? Because when I try to go to mattswebsite.org/wp-admin, I'm redirected to the homepage whether or not I am logged in.

You must go to mattswebsite.org/wp-login.php and log in using your Commons credentials.

aha! Thank you.

Hi All --

I'm open to whatever you think is best in terms of implementing now or waiting for Letsencrypt. I guess it's a matter of how soon browsers will be adding these security warnings -- if soon, then we should act soon; if it will take a year or so for the new warnings to really be in place, we can likely wait for IT to implement LE.

If we do move forward, please make the following changes in the warning:

-- "our domain mapping feature" --> "the CUNY Academic Commons's domain mapping feature"

-- "your Commons' admin dashboard" --> "the Commons's admin dashboard"

-- in the last line, can you please add "but this should not change the functionality of your site in any way. If you notice any problems, please email us at support@cunycommons.zendesk.com "

Thanks, Ray! I will tool around with this on cdev, but it looks great at a glance.

I think we need to move forward with this right away. The main concern here is that mapped domain admins are currently sending login credentials in the clear. The secondary concern is that they're doing potentially sensitive website administration in the clear. Moving administration to SSL is the right move for security reasons, regardless of browser policies. (The potential audience for the message you've built is pretty small, since we don't have a huge number of people administering mapped-domain sites. So I think we don't have to worry too much about obstrusiveness.)

Embarrasingly, you're right.

The problem is due to mixed content requests:

Mixed Content: The page at 'https://commons.gc.cuny.edu/wp-login.php' was loaded over HTTPS, but requested an insecure script 'http://crc15.org/?action=sso-login&sso=XXX%3D&callback=loadSitesCB&_=XXX'. This request has been blocked; the content must be served over HTTPS.

My secondary Firefox profile had the following setting enabled:

security.mixed_content.block_active_content = false (Edited - Meant to write false and not true!)

Which is why those requests were allowed and was able to set the login cookies. Most browsers block mixed content requests by default nowadays.

The main problem of this ticket was using SSL for administering and logging in from mapped domains. This should still be addressed and can still be tested on cdev.

In the meantime, I've disabled the WP Multisite SSO plugin on cdev. It would have been nice to include SSO for v1.13, but we'll have to wait until we get Let's Encrypt working for our mapped domains. At least we'll be ready for it when that time comes.

Got it. Thanks for the explanation - this squares with my (limited) understanding.

To be clear, this does mean (if I'm understanding correctly) that there is no way for a user to set the auth cookies for a mapped domain. wp-login.php requests always redirect to the main Commons site. This means that the Commons toolbar will always show the logged-out view on the front end. Is this correct, or is there some workaround (like maybe a URL param you can pass to wp-login that will prevent the redirect)? The main reason I ask is so that we can be clear in our documentation and in case we get support requests along these lines.

wp-login.php requests always redirect to the main Commons site. This means that the Commons toolbar will always show the logged-out view on the front end. Is this correct, or is there some workaround (like maybe a URL param you can pass to wp-login that will prevent the redirect)?

I've just pushed a commit that allows you to bypass the main site login if you're on a mapped domain:
https://github.com/cuny-academic-commons/cac/commit/7bc9a391fa3cfc46d43f29fc92cbe338b11ce1d6

So let's say you're on http://crc15.org and you want to force login to crc15.org, you can use the force query parameter -- http://crc15.org/?force -- and this will allow you to force the login to the mapped domain instead of using the main site to login when using the login form dropdown. The login will use HTTP in this case though.

Let me know if this is okay.

Thanks, Ray. I know that this is clunky and not ideal, so I appreciate your sticking with it :)

I think the behavior you've put in place is a fine compromise. Ideally, no one will ever use it. But there may be instances where users are very confused about the fact that they're not logged in on the front end. In these cases, it's nice to have this option available.

Everything is working as advertised, so I think we're about ready to mark this one resolved. Ray, could you please be sure to update this page https://github.com/cuny-academic-commons/cac/wiki/Release-ACTION_REQUIRED-list so that I'll know what needs to be done after release?

Done. I've updated the ACTION_REQUIRED list as you'll need to make a change to the WPMU Domain Mapping settings.