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.

We can fire it ourselves.

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

Does that look right?

Replying to nacin:

We can fire it ourselves.

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

Works for me.

Looks good.

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

In [21019]:

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

We should probably do:

if ( is_admin() && ! defined( 'DOING_AJAX' ) ) {
    auth_redirect();
} 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.

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.

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.

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?

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

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

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.

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.

AJAX check will be handled in #20876.