#20926 closed defect (bug) (fixed)
Theme Customizer should trigger the frontend if logged-in cookie is missing
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.4 | Priority: | normal |
Severity: | normal | Version: | 3.4 |
Component: | Customize | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
A remote-login script is typically used in a domain mapping situation. This allows logins and administration to occur on the non-mapped domain, but for the logged-in cookie to be issued when the frontend is browsed. Both WP.com and the de facto official domain mapping plugin do this.
The customizer implements an is_user_logged_in() check during previews. This happens in two situations:
- When the person's cookies expire.
- When the person never had a front-end cookie.
We already handle point 1 by catching die( '0' ) and sending them to wp-login.php.
In the case of point 2, they will see an unmapped wp-login.php screen, which will allow them to log in over and over again.
To fix point 2, we can check if the person has a front-end cookie when we receive a die( '0' ). To do this, we can check if they have an admin cookie via admin-ajax. If they don't, we know they are just not logged in and need to visit wp-login.php.
If they do, then we know they are just missing a front-end cookie, which means we can hit the front page the front-page with an ajax request, with the hope of triggering a remote-login. If it doesn't work, we can send just them back to the potentially infinite loop that is wp-login.php, in case they have a *mapped* wp-login.php, which can likely happen if you roll your own mapping.
Attached patch implements a simple admin-ajax.php?action=logged-in handler that dies with either 1 or 0.
Patch enhances the PreviewFrame to check if the user has admin cookies, load the front page, and then attempt the request again. If the request still fails, it will defer to the login form.