[wp-trac] [WordPress Trac] #50781: 500 error caused by customize_changeset_uuid for non-authenticated users

[WordPress Trac]

#50781: 500 error caused by customize_changeset_uuid for non-authenticated users
-------------------------------------------------+-------------------------
 Reporter:  bacardy4                             |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  6.2
Component:  Customize                            |     Version:  4.7
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests needs-testing       |     Focuses:
  needs-patch 2nd-opinion                        |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 I'm confused by this point in the description:

 > I have noticed that if a non-authenticated user visits a URL containing
 the following get parameter: `?customize_changeset_uuid=SOME_ID_HERE`
 WordPress returns 500 error.

 A key purpose of changesets is specifically to allow unauthenticated users
 to preview changes. I can see this indeed works as expected, if I make a
 change in the Customizer and save the changes as a draft. When I do so, a
 preview URL is presented in the UI with the `customize_changeset_uuid`
 parameter added.

 Nevertheless, if I start making changes in the Customizer and I have
 ''not'' explicitly saved a draft yet, then the Customizer will stash the
 changes in a `wp_customize_changeset` post with an autosave status. In
 this case, if I try copying one of the links in the Customizer preview and
 accessing it as an unauthenticated user, I then will get the described
 error, ''but'' only because the link includes additional parameters,
 namely `customize_autosaved=on` and
 `customize_messenger_channel=preview-1`. Nevertheless, if I remove those
 parameters then it loads as expected. So something isn't quite right here.

 In the case of an invalid UUID which fails to match `wp_is_uuid()`, I
 think a `400 Bad Request` response makes the most sense. But a `404`
 response would be ''OK'' (not `200` though! 😉)

 In the case of a valid UUID that no longer corresponds to a
 `wp_customize_changeset` post, there would be two possible reasons for
 this:

 1. The changeset was published, meaning the changes are now live.
 2. The changeset never existed in the first place.

 In the first case, a status of `410 Gone` would make sense, but since the
 changeset is deleted there wouldn't be a way to know it used to exist to
 differentiate it from the second case above. A `301 Moved Permanently`
 would also make sense, but that would miss an opportunity to communicate
 to the user explicitly that the changes are now live or that the changes
 couldn't be found.

 Another possibility here would be to return a `300 Multiple Choices`
 response. The body here would say that either the changeset has been
 published, in which case there can be a link with the
 `customize_changeset_uuid` parameter removed (in other words a manual
 redirect). Otherwise, there can also be a note saying that the changeset
 may not have ever existed in the first place (in other words a manual
 404). I think this would be best.

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