Bug #22728
openAccessing Dashboard on site with mapped domain
0%
Description
Hi All,
Strange issue here. Commons user, Miranda (mfedock), is trying to access https://cunyhumanitiesalliance.org/, which is a site on the commons with a mapped domain. She is an admin.
Even when she is logged into the commons, and she goes to this site, she cannot get into the dashboard because the commons reads her as logged out when accessing the site. We have tried 3 browsers and clearing cache multiple times. (video 1)
Even stranger, when she tried on my computer (video 2), she could not log into the commons, even though this is the username/password combo she just used on her own computer (video 1)
Colin had helped her move the domains over during the migration and she forwarded me those messages, which ill include excepts of below, in case the mapping is part of the issue. (weirdly, her domain host is reclaim, and they did not support the methods we used for mapping so COlin helped her figure out a workaround, I guess)
From the mapping process emails
Miranda: Our original domain registrar, Reclaim Hosting, didn’t support CNAME flattening, so we transferred the domain to Cloudflare. I was notified that the transfer was approved and went through yesterday – however, the website itself is still down (cunyhumanitiesalliance.org), and I can’t figure out why. Any help you can offer would be appreciated. Thanks so much.
Colin:
We have had many users dealing with a lack of CNAME flattening support from their registrars. Thank you for taking that step of changing to Cloudflare in order to get around it. In the meantime, we actually figured out a way to keep using A records. I am not sure if this will help get the site back (I can say more once I have that screenshot), but you could try going back to the A record that you had before pointing to 146.96.128.200. Just make sure to also delete any new CNAME record(s) that you made.
If the A record does the trick, you can keep using it after we migrate hosts, but it will need to be changed to point to 15.204.146.102 instead. However, you should ONLY make that change after our migration downtime begins at 10:30am on Wednesday the 15th. The downtime will go until at least Friday morning, so you could make the change at any point in that time window. Then everything will be ready to go when the downtime ends and the Commons comes back on its new host.
....
I'd recommend removing the "www" CNAME record pointing to the Commons URL, then restoring the A record you had before pointing to 146.96.128.200 and with the "
" symbol for the Name field so it covers the root domain. If you can do that today it should bring the site back, and then at some point between tomorrow and Friday morning, when the Commons is fully down for our host migration, you can change the "
" A record to 15.204.146.102 so it's ready when the Commons comes back.
Files
Updated by Boone Gorges 2 days ago
- Assignee set to Raymond Hoh
Laurie, thanks for the very detailed ticket.
Part of the behavior you describe is normal and by design. Users must, in fact, log in separately when visiting a mapped domain (at least when they do it via a certain navigation path) - this was a compromise when we changed the way our domain mapping worked after the Reclaim migration. (Not sure what to say about video 2 - this must be user error or something.)
The crux of the issue here appears to be that the login page is broken: https://cunyhumanitiesalliance.org/wp-login.php. Ray, by the looks of things, this has something to do with our method for injecting the login page into the current theme. Could you have a look to see if I'm right about this?
Updated by Raymond Hoh 2 days ago
- Category name set to Layout
- Status changed from New to Reporter Feedback
- Target version set to 2.5.8
The issue is with the 'textbook'
theme.
The 'textbook'
theme uses a CSS 'opacity: 0'
rule by default: https://themes.trac.wordpress.org/browser/textbook/1.1.6/style.css#L1592
This causes the page to look like nothing is rendered. Later on page load, the 'textbook'
theme tries to do a fancy fade-in with JS on load: https://themes.trac.wordpress.org/browser/textbook/1.1.6/assets/js/functions.js#L56
This JS isn't loaded on our custom login page, which causes the login page to look like nothing is rendered. I've added a commit to override the 'opacity'
CSS rule to always force the body to be shown in https://github.com/cuny-academic-commons/cac/commit/54b0890b18e380bfc346fccd2b0bf469a878b166. Fix is also live on production.
Let me know if the login page is visible now for the cunyhumanitiesalliance.org
site.
Updated by Raymond Hoh 2 days ago
While looking at video 1 to see the user's login flow, it dawned on me that maybe we should use the same SSO method that we use when accessing the admin bar's 'My Sites' menu for the 'My Sites' section on the logged-in homepage as well. This would allow users to directly login to their mapped domain when clicking on the site's link from the "My Sites" portion of the logged-in homepage. I'm going to look into this.
Boone and Laurie, would it also make sense to use this same SSO method when on your own "Commons Profile > Sites" page as well -- https://commons.gc.cuny.edu/members/me/blogs/?
The one negative I can think of when switching out the site URL for the SSO URL is this might cause the user to unintentionally copy and paste the SSO URL into emails or other forms of communications. If the URL is used within two minutes, anyone could login as the user. If the link is used past that time frame, an error message will be displayed asking the user to login.
Updated by Boone Gorges 2 days ago
The one negative I can think of when switching out the site URL for the SSO URL is this might cause the user to unintentionally copy and paste the SSO URL into emails or other forms of communications. If the URL is used within two minutes, anyone could login as the user. If the link is used past that time frame, an error message will be displayed asking the user to login.
This is definitely an edge case, but it seems like a pretty bad one. I guess I'd say let's err on the side of caution and not use these links here.
Updated by Raymond Hoh 1 day ago
I guess I'd say let's err on the side of caution and not use these links here.
Agreed. Will hold off on the SSO URL rewriting.