WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#20872 closed defect (bug) (fixed)

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

Reported by: ocean90 Owned by: nacin
Milestone: 3.4 Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (1)

20872.patch (574 bytes) - added by ocean90 3 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 follow-up: @nacin3 years ago

We can fire it ourselves.

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

Does that look right?

@ocean903 years ago

comment:2 in reply to: ↑ 1 @ocean903 years ago

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

Replying to nacin:

We can fire it ourselves.

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

Works for me.

comment:3 @SergeyBiryukov3 years ago

  • Keywords has-patch added; needs-patch removed

comment:4 @ryan3 years ago

Looks good.

comment:5 @ryan3 years ago

  • Keywords commit added; dev-feedback removed

comment:6 @nacin3 years ago

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

comment:7 @nacin3 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [21019]:

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

comment:8 follow-up: @nacin3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

Last edited 3 years ago by nacin (previous) (diff)

comment:9 @nacin3 years ago

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.

comment:10 in reply to: ↑ 8 @koopersmith3 years ago

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.

comment:11 @nacin3 years ago

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?

comment:12 @ryan3 years ago

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

comment:13 @ryan3 years ago

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

comment:14 @ryan3 years ago

  • Keywords commit removed

comment:15 @ryan3 years ago

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.

Last edited 3 years ago by ryan (previous) (diff)

comment:16 @ocean903 years ago

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.

comment:17 @ocean903 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

AJAX check will be handled in #20876.

Note: See TracTickets for help on using tickets.