Project

General

Profile

Actions

Feature #5525

closed

Mapped domains should be administered over *.commons.gc.cuny.edu

Added by Boone Gorges over 8 years ago. Updated over 6 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
Domain Mapping
Target version:
Start date:
2016-05-03
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

We should see what we can do about forcing all administration on mapped domains to take place over *.commons.gc.cuny.edu. This change will help us to meet CUNY's requirements about "transactional" domains requiring SSL/TLS; *.commons.gc.cuny.edu/wp-admin is forced HTTPS, while most mapped domains don't have SSL certs at all.

I think that the WordPress MU Domain Mapping plugin supports this configuration, but there are some things to check:

- Shared cookies/logins between domains. If I've mapped foo.com to foo.commons.gc.cuny.edu, and I log into foo.commons.gc.cuny.edu, I should probably also be logged into foo.com. (I don't think this is absolutely critical, but it would result in a much smoother experience, especially as regards the appearance of the toolbar on the front end.) See #1508.
- I thought there was something else, but it escapes me at the moment :)

Adding Ray as a watcher - Ray, if you have any experience with this kind of config, or ideas about how best to implement, your help would be appreciated.


Files

2018-04-23_114818.png (8.39 KB) 2018-04-23_114818.png Raymond Hoh, 2018-04-23 02:50 PM
Screenshot_2018-04-23_21-30-38.png (137 KB) Screenshot_2018-04-23_21-30-38.png Boone Gorges, 2018-04-23 05:33 PM
Screenshot_2018-04-23_21-30-56.png (141 KB) Screenshot_2018-04-23_21-30-56.png Boone Gorges, 2018-04-23 05:33 PM

Related issues

Related to CUNY Academic Commons - Bug #6650: Force SSL for *.commons.gc.cuny.edu pagesResolvedBoone Gorges2016-11-08

Actions
Related to CUNY Academic Commons - Feature #9907: Ability to change error page for non-approved users?ResolvedRaymond Hoh2018-06-08

Actions
Related to CUNY Academic Commons - Bug #13455: Switch from WPMU Domain Mapping to MercatorResolvedRaymond Hoh2020-10-10

Actions
Related to CUNY Academic Commons - Support #17194: Plugin: WP Multisite SSOResolvedBoone Gorges2022-11-07

Actions
Actions #1

Updated by Matt Gold over 8 years ago

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

Actions #2

Updated by Raymond Hoh over 8 years ago

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

The code I wrote does a couple of things:
  • 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.

Actions #3

Updated by Boone Gorges over 8 years ago

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?

Actions #4

Updated by Raymond Hoh over 8 years ago

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.

Actions #5

Updated by Boone Gorges about 8 years ago

  • Related to Bug #6650: Force SSL for *.commons.gc.cuny.edu pages added
Actions #6

Updated by Boone Gorges about 7 years ago

  • Assignee changed from Boone Gorges to Raymond Hoh
  • Target version changed from Not tracked to 1.13

I forgot about this. We should do it. Ray, can I ask you to put it on your roadmap? If you've got a few domains that you can map to cdev for testing, please do so - otherwise I could lend one or two.

Actions #7

Updated by Raymond Hoh about 7 years ago

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?

Actions #8

Updated by Boone Gorges about 7 years ago

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.

Actions #9

Updated by Raymond Hoh about 7 years ago

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?

Actions #10

Updated by Boone Gorges about 7 years ago

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

Actions #11

Updated by Raymond Hoh about 7 years ago

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.

Actions #12

Updated by Boone Gorges about 7 years ago

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.

Actions #13

Updated by Raymond Hoh almost 7 years ago

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

Actions #14

Updated by Matt Gold almost 7 years ago

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.

Actions #15

Updated by Boone Gorges over 6 years ago

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.

Actions #16

Updated by Matt Gold over 6 years ago

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?

Actions #17

Updated by Boone Gorges over 6 years ago

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.

Actions #18

Updated by Raymond Hoh over 6 years ago

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.

Actions #19

Updated by Matt Gold over 6 years ago

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.

Actions #20

Updated by Boone Gorges over 6 years ago

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

Actions #21

Updated by Matt Gold over 6 years ago

aha! Thank you.

Actions #22

Updated by Raymond Hoh over 6 years ago

I've added the WP Multisite SSO plugin, as well as some modifications to use the main site's login URL when a user is on a mapped domain:
https://github.com/cuny-academic-commons/cac/compare/1ef57d44b0...4ce44e335c

The WP Multisite SSO plugin I've committed is a light fork of the original. The authors plan to merge my last pull request, but they haven't done so yet.

The reason we needed this ticket to begin with was due to the need to use HTTPS in the admin dashboard. However, since IT has agreed to implement Let's Encrypt for our mapped domains, we will no longer need to resort to forcing logins to the main site if a user is on a mapped domain. When that time comes, we can revert this commit:
https://github.com/cuny-academic-commons/cac/commit/4ce44e335cc48fe72da28bd785becbd1cb311e5e

What happens at the moment is if you attempt to go to a mapped domain's dashboard, you'll get redirected to the Commons subdomain dashboard with a notice that looks like this:

Is the notice too obtrusive or confusing? Is it unnecesary? Or should we wait for IT to implement Let's Encrypt?

Testing requirements are the same as what I noted in comment 18 above.

Actions #23

Updated by Matt Gold over 6 years ago

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 "

Actions #24

Updated by Boone Gorges over 6 years ago

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

Actions #25

Updated by Boone Gorges over 6 years ago

Playing around with this, I'm unable to get the mapped-domain login cookies set. For example, I can see that the browser is trying to send an 'sso-login' request to http://crc15.org, but it's failing. I'm afraid I don't really understand the console output here - see attached screenshots. I know you mentioned that this would only work if third-party cookies were enabled, but this is turned on in my browser, and in any case it looks like the browser is blocking the request, not the setting of the cookie. Could this have something to do with strict-origin-when-cross-origin?

Actions #26

Updated by Raymond Hoh over 6 years ago

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.

Actions #27

Updated by Boone Gorges over 6 years ago

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.

Actions #28

Updated by Raymond Hoh over 6 years ago

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.

Actions #29

Updated by Boone Gorges over 6 years ago

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?

Actions #30

Updated by Raymond Hoh over 6 years ago

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

Actions #31

Updated by Boone Gorges over 6 years ago

  • Status changed from Testing Required to Resolved

Thank you sir!

Actions #32

Updated by Raymond Hoh over 6 years ago

  • Related to Feature #9907: Ability to change error page for non-approved users? added
Actions #33

Updated by Raymond Hoh about 4 years ago

  • Related to Bug #13455: Switch from WPMU Domain Mapping to Mercator added
Actions #34

Updated by Boone Gorges about 2 years ago

Actions

Also available in: Atom PDF