Customizer: Accessing /wp-admin/customize.php doesn't redirect to wp-login.php when not logged in

[ocean90]

I just sent the direct link to the Customizer domain.com/wp-admin/customize.php to a friend and he only got a Cheatin’ uh? message.

The problem is, that we include the admin.php in customize.php. admin.php includes wp-load.php which includes wp-settings.php.
do_action( 'plugins_loaded' ); is fired.
_wp_customize_include() is fired.
WP_Customize_Manager::setup_theme() is fired.

In setup_theme()

if ( ! current_user_can( 'edit_theme_options' ) )
	wp_die( __( 'Cheatin’ uh?' ) );

fails.

The main issue is, that auth_redirect() can't be fired since the Customizer runs before this action.

[nacin]

We can fire it ourselves.

if ( is_admin() && ! defined( 'DOING_AJAX' ) )
    auth_redirect();

Does that look right?

[ocean90]

Replying to nacin:

We can fire it ourselves.

if ( is_admin() && ! defined( 'DOING_AJAX' ) )
    auth_redirect();

Works for me.

[ryan]

Looks good.

[nacin]

This works when customize.php is loaded inside a frame on themes.php, too. Nice!

[nacin]

In [21019]:

Call auth_redirect() for customize.php. props ocean90. fixes #20872.

[nacin]

We should probably do:

if ( is_admin() && ! defined( 'DOING_AJAX' ) ) {

} elseif ( defined( 'DOING_AJAX' ) && ! is_user_logged_in() ) {
    wp_die( -1 );
} elseif ( ! is_user_logged_in() ) {
    // redirect to login for the preview
}

For the ajax check, see #20876.

[nacin]

This is because a logged-in cookie could be lost even with an auth cookie in place. Not typical, but can occur with mapped domains pretty easily.

[koopersmith]

Replying to nacin:

We should probably do:

... defined( 'DOING_AJAX' ) ...

Since we're running the preview ajax requests through the front end (instead of admin-ajax), DOING_AJAX will not be (and should not be) defined, so we shouldn't have to check for it.

[nacin]

Since we're running the preview ajax requests through the front end (instead of admin-ajax), DOING_AJAX will not be (and should not be) defined, so we shouldn't have to check for it.

Save runs through admin-ajax, no?

[ryan]

I don't see any saves triggering ::setup_theme(). The reloads that are triggered for header and such aren't DOING_AJAX.

[ryan]

Sorry. When I said saves I meant updates/refreshes. Clicking the save button is indeed DOING_AJAX and setup_theme() is triggered.

[ryan]

Handling a redirect in the preview could be tricky, especially with the wp_redirect_status override. How about something like:

if ( is_admin() && ! defined( 'DOING_AJAX' ) ) {
    auth_redirect();
} elseif ( defined( 'DOING_AJAX' ) && ! is_user_logged_in() ) {
    wp_die( -1 );
} elseif ( ! is_user_logged_in() ) {
   echo 'WP_CUSTOMIZER_NOT_LOGGED_IN';
   die;
}

Check for WP_CUSTOMIZER_NOT_LOGGED_IN in api.PreviewFrame. If found output a please log in message and a link to wp-login.php with redirect_to set to the customizer.

[ocean90]

Instead of WP_CUSTOMIZER_NOT_LOGGED_IN we could also use wp_die() and the ajax wp_die handler, see ​http://core.trac.wordpress.org/attachment/ticket/20876/20876.patch.

[ocean90]

AJAX check will be handled in #20876.