Bug #14458
closedMapped domains result in unresolving login redirect on non-public sites
0%
Description
Here's the setup:
- A site is marked with blog_public < 0. Say, 3 (site administrators only) You map a domain to it and set it to 'Active'
- Try to visit either the mapped or unmapped version
- You are redirected to https://commons.gc.cuny.edu/wp-login.php?p=-3&redirect_to=[mappeddomain]. This happens even if you're logged in - the mapped domain cookie doesn't seem to be set
- Try logging in, and you end up back at the same login page.
The stack trace for the redirect is:
require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), do_action('template_redirect'), WP_Hook->do_action, WP_Hook->apply_filters, cac_mpo_adminsonly_die, cac_mpo_unauthenticated_redirect, auth_redirect, wp_redirect
Maybe the blog_public setting is preventing the asynchronous cookie setting? Ray, could you have a look?
Files
Related issues
Updated by Boone Gorges almost 3 years ago
- Related to Support #14452: domain mapping - hilarieashton.com added
Updated by Raymond Hoh almost 3 years ago
Maybe the blog_public setting is preventing the asynchronous cookie setting? Ray, could you have a look?
That's correct.
The asynchronous cookie call happens on the mapped domain in the <head> of the document, which is later than the server-side blog privacy enforcement on the template_redirect hook.
One way to address this is to disable the mapped domain redirect if the site has a blog_public < 0 and if the user is logged-in. That means when a user logs into their private mapped domain site, no mapped domain redirect will occur and the navigation will take place on the subdomain.
This is kind of an edge-case, but does that sound like a good compromise? Any other method would require doing checks and redirects via javascript, which can be bypassed.
Updated by Raymond Hoh almost 3 years ago
Okay, I've implemented a different method.
When you attempt to login to a private mapped domain, on successful login, you will now see a splash page saying "Please wait. Attempting authentication". On this page, I can load up Mercator's async JS cookie method so the SSO routine can complete. Once the SSO routine completes, the user is redirected back to the mapped domain and should be able to view the site.
I haven't committed these changes yet, but they are live on production. The downsides with this approach is javascript and 3rd-party cookies need to be enabled (or commons.gc.cuny.edu needs to be in the cookie exemption list in the browser) in order for SSO to complete. Otherwise, the user will be stuck on the splash page.
Boone, let me know what you think of this approach.
Updated by Boone Gorges almost 3 years ago
Thanks for thinking about this, Ray.
My main concern is that we eliminate dead-ends. Prior to your change, there was really no way to access or log into these mapped domains. It sounds like now it should be seamless, unless the browser blocks third-party cookies. But most people won't need to log into mapped domains (just the administrators, and those who need access to a private site), and there's no dead-end for these users because they can simply add commons.gc.cuny.edu to their exemption list. Does this sound right to you? Do you think it warrants an addition to our documentation on mapped domains?
Updated by Raymond Hoh almost 3 years ago
- File splash-page.png splash-page.png added
- Status changed from New to Resolved
- Target version set to 1.18.11
I've committed the second approach mentioned above here: https://github.com/cuny-academic-commons/cac/commit/3ffe57f4c1fb8ce624ded3af84dff26718494d7d
The splash page looks like this:
Let me know if anything needs to be changed on the splash page.
On the call last week, we briefly talked about the first option -- redirecting logged-in users back to the subdomain instead of the mapped domain -- but I decided to hold off on this since we would be changing the current mapped domain behavior between major releases. I've opened a new broader ticket to deal with this and the impending browser blocking of third-party cookies -- #14496.