[wp-trac] [WordPress Trac] #39128: Customize: Preview fails to load when domain mapping in use (home/siteurl domain mismatch)

[WordPress Trac]

#39128: Customize: Preview fails to load when domain mapping in use (home/siteurl
domain mismatch)
--------------------------+-----------------------
 Reporter:  RomainVB      |       Owner:
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  4.7.3
Component:  Customize     |     Version:  4.7
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------
Changes (by westonruter):

 * keywords:  reporter-feedback => needs-patch


Comment:

 Replying to [comment:37 ocean90]:
 > I just stumbled upon this. From first looking I disagree with `wontfix`.
 I remember that we put a lot of work into this to make it working
 properly, related tickets are #20582 and #20507.

 OK, thanks a lot for your input here!

 > @westonruter Could it be because
 https://core.trac.wordpress.org/browser/tags/4.6.2/src/wp-admin/js
 /customize-controls.js?marks=2990#L2986 no longer exists since 4.7?

 The content for the customizer preview is no longer being fetched via
 Ajax, that's right. Instead the preview URL is being loaded directly into
 the iframe via its `src` or via a `form` POST into the iframe window. In
 both of these cases, credentials should be getting sent if the user has a
 cookie set on the frontend, right? However, if I try accessing the wp-
 admin on the `siteurl` domain and log-in, no cookie gets set on the `home`
 domain, so I don't see how credentials would be getting passed even over
 Ajax `withCredentials`. See [attachment:missing-cookie-request-
 header.png].

 > Also, [https://core.trac.wordpress.org/browser/tags/4.7.2/src/wp-
 includes/class-wp-customize-manager.php?marks=497#L466 the position of the
 send_origin_headers() call] looks odd, I think it should be
 [https://core.trac.wordpress.org/browser/tags/4.6.2/src/wp-includes/class-
 wp-customize-manager.php?marks=378#L377 at the same position as before].

 Yeah, you're probably right. Nevertheless, I think that only matters for
 Ajax requests since only XHR requests include the `Origin:` header AFAIK.
 Non-XHR requests do not include `Origin` though they may include
 `Referer`.

 > '''Edit:''' I just downgraded an affected site to 4.6.3 and it's still
 kind of broken. Instead of the "non existing changeset UUID" error I get
 the login form.

 This is what I see as well. Going back even to 4.3. It seems cross-domain
 support has been broken for some time.

 It seems that in both the case of XHR (using `withCredentials`) and non-
 XHR (regular browser `GET` and `POST` requests) there needs to ensure that
 the user has also authenticated on the `home` domain to ensure auth
 cookies are present. This is probably much more secure than my original
 suggestion to add some auth token to the query params that get added to
 customizer preview URLs, since they would then be able to be read by any
 script on the page and could potentially be used by a 3rd party to gain
 access. Better to ensure that HttpOnly cookies are used.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39128#comment:38>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform