Bug #14458
closed
Mapped domains result in unresolving login redirect on non-public sites
Added by Boone Gorges almost 3 years ago.
Updated almost 3 years ago.
Category name:
Domain Mapping
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
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.
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.
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?
Also available in: Atom
PDF
