Право read пользователя WordPress

право read пользователя WordPress

право пользователя read

Возникал ли у вас когда-либо вопрос, а что, собственно, право read пользователя WordPress позволяет читать? Любой незарегистрированный посетитель вашего блога может видеть и читать любую общедоступную (публичную) статью (пост) безо каких-либо ограничений. Каково же тогда назначение права пользователя ‘read’? После небольшого исследования я пришел к заключению, что по текущему состоянию право пользователя ‘read’ точнее было бы назвать, например, ‘user_profile’ (профайл пользователя). На чём основан такой вывод? Право ‘read’ пользователя WordPress отвечает за доступ только к этим пунктам меню WordPress:
“Консоль”-“Главная”, “Консоль”-“Мои сайты” (для много-сайтовой установки WordPress) и “Профиль”-“Ваш профиль”.
Таким образом, если вы исключите у пользователя право ‘read’, он потеряет доступ к своему пользовательскому профилю. После логина при попытке открыть консоль WordPress такой пользователь получит от WordPress сообщение об ошибке: “У вас недостаточно полномочий для доступа к этой странице”.

Страница Codex WordPress утверждает, что:
право ‘read’ введено в действие, начиная с версии 2.0, это право открывает доступ к следующим опциям панели Администратора: Консоль, Пользователит > Ваш профиль
и не используется в базовом коде WordPress за исключением menu.php. И, хотя о доступных пунктах меню на Codex сказана полная правда, информация об использования права пользователя ‘read’ в исходном коде WordPress уже слегка устарела. Давайте вместе посмотрим на исходный код WordPress и попробуем понять, с какой же истинной целью разработчики WordPress реализовали право пользователя ‘read’.

Право read пользователя WordPress в PHP файлах

Использование права ‘read’ пользователя WordPress обнаружено мной в следующих .php файлах ядра WordPress:

Исходный код

wp-login.php: Право пользователя ‘read’ встречается здесь в единственном месте, фрагмент имеющего отношение к делу кода начинается со строки 631:

631
632
633
634
635
636
637
638
639
640
641
	if ( ( empty( $redirect_to ) || $redirect_to == 'wp-admin/' || $redirect_to == admin_url() ) ) {
		// If the user doesn't belong to a blog, send them to user admin. If the user can't edit posts, send them to their profile.
		if ( is_multisite() && !get_active_blog_for_user($user->ID) && !is_super_admin( $user->ID ) )
			$redirect_to = user_admin_url();
		elseif ( is_multisite() && !$user->has_cap('read') )
			$redirect_to = get_dashboard_url( $user->ID );
		elseif ( !$user->has_cap('edit_posts') )
			$redirect_to = admin_url('profile.php');
	}
	wp_safe_redirect($redirect_to);
	exit();

Как видно из приведенного выше фрагмента исходного кода (см. строку 636), если пользователь не обладает правом ‘read’ для много-сайтовой установки, он будет перенаправлен на собственную консоль. Функция get_dashboard_url() работает так: Если пользователь не принадлежит ни одному сайту, используется глобальная консоль пользоватея. Если пользователь принадлежит текущему сайту, функция возвращает консоль для текущего сайта. Если пользователь не может редактировать текущий сайт, функция возвращает консоль для главного (первичного) блога. Во всех других случаях, когда блог сконфигурирован, как единственный сайт, или у пользователя есть право ‘read’, WordPress перенаправит его сразу на страницу его профайла.

wp-includes/capabilities.php: Согласно комментариям в исходном коде функция map_meta_cap() из этого файла “задает отображение так называемых “мета” прав на при “примитивные” права пользователя”. В контексте нашего исследования эта функция отображает мета-права ‘read_post’ и ‘read_page’ на право ‘read’ для общедоступных элементов стандартных типов ‘post’ (статья-пост) и ‘page’ (страница) (line #1133) или соответсвующие права доступа для общедоступных элементов из определенных пользователем типов (custom), если они определены:

1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
	case 'read_post':
	case 'read_page':
		$post = get_post( $args[0] );
 
		if ( 'revision' == $post->post_type ) {
			$post = get_post( $post->post_parent );
		}
 
		$post_type = get_post_type_object( $post->post_type );
 
		if ( ! $post_type->map_meta_cap ) {
			$caps[] = $post_type->cap->$cap;
			// Prior to 3.1 we would re-call map_meta_cap here.
			if ( 'read_post' == $cap )
				$cap = $post_type->cap->$cap;
			break;
		}
 
		$status_obj = get_post_status_object( $post->post_status );
		if ( $status_obj->public ) {
			$caps[] = $post_type->cap->read;
			break;
		}

wp-includes/post.php: Этот файл использует право ‘read’ только для отображения его на такое же право ‘read’ для стандартного типа ‘post’, которое далее будет преобразовано во встреченные нами выше ‘read_post’ или ‘read_page’, смотрите на строку 1430:

1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
	// Primitive capabilities used within map_meta_cap():
	if ( $args->map_meta_cap ) {
		$default_capabilities_for_mapping = array(
			'read'                   => 'read',
			'delete_posts'           => 'delete_'           . $plural_base,
			'delete_private_posts'   => 'delete_private_'   . $plural_base,
			'delete_published_posts' => 'delete_published_' . $plural_base,
			'delete_others_posts'    => 'delete_others_'    . $plural_base,
			'edit_private_posts'     => 'edit_private_'     . $plural_base,
			'edit_published_posts'   => 'edit_published_'   . $plural_base,
		);
		$default_capabilities = array_merge( $default_capabilities, $default_capabilities_for_mapping );
	}

И хотя право ‘read’ определено как одно из ключевых прав доступа к содержанию ваших статей и страниц, я не обнаружил в исходном коде никаких ограничений на доступ к публичному (общедоступному) содержимому для незарегистрированных пользователей или зарегистрированных и “залогинившихся”, но не обладающих правом ‘read’. Без права ‘read’ пользователь теряет доступ только к консоли WordPress и профайлу пользователя. Просмотр файла wp-admin/menu.php только подтверждает этот вывод.

wp-admin/menu.php: Этот файл использует право ‘read’ для ограничения доступа к определенному набору пунктов меню администратора WordPress:

25
26
27
28
29
30
31
$menu[2] = array( __('Dashboard'), 'read', 'index.php', '', 'menu-top menu-top-first menu-icon-dashboard', 'menu-dashboard', 'none' );
 
$submenu[ 'index.php' ][0] = array( __('Home'), 'read', 'index.php' );
 
if ( is_multisite() ) {
	$submenu[ 'index.php' ][5] = array( __('My Sites'), 'read', 'my-sites.php' );
}

Как показано выше, эти пункты меню: ‘Консоль’, ‘Главная’ и ‘Мои Сайты’ (для много-сайтовой установки WordPress).

Следующее вхождение права ‘read’ в этом файле это строка #42, в которой право ‘read’ используется для проверки доступа к … Это выглядело бы шуткой, если бы не было правдой – право ‘read’ используется здесь для предоставления доступа к разделительной линии между разными меню администратора :).

42
  $menu[4] = array( '', 'read', 'separator1', '', 'wp-menu-separator' );

Точно такой же код обнаружен в строке #137

137
  $menu[59] = array( '', 'read', 'separator2', '', 'wp-menu-separator' );

Это лишний раз показывает реальный уровень ответственности, закрепленный разработчиками WordPress за правом пользователя ‘read’. Право ‘read’ может быть доступно практически любому зарегистрированному пользователю WordPress. Единственный случай, когда вам может потребоваться отобрать у пользователя право ‘read’, это случай, когда вы планируете запретить пользователям доступ к их пользовательским профайлам. Взгляните на исходный PHP код ниже. Нас интересуют строки 181, 191 and 194:

178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
if ( current_user_can('list_users') )
	$menu[70] = array( __('Users'), 'list_users', 'users.php', '', 'menu-top menu-icon-users', 'menu-users', 'none' );
else
	$menu[70] = array( __('Profile'), 'read', 'profile.php', '', 'menu-top menu-icon-users', 'menu-users', 'none' );
 
if ( current_user_can('list_users') ) {
	$_wp_real_parent_file['profile.php'] = 'users.php'; // Back-compat for plugins adding submenus to profile.php.
	$submenu['users.php'][5] = array(__('All Users'), 'list_users', 'users.php');
	if ( current_user_can('create_users') )
		$submenu['users.php'][10] = array(_x('Add New', 'user'), 'create_users', 'user-new.php');
	else
		$submenu['users.php'][10] = array(_x('Add New', 'user'), 'promote_users', 'user-new.php');
 
	$submenu['users.php'][15] = array(__('Your Profile'), 'read', 'profile.php');
} else {
	$_wp_real_parent_file['users.php'] = 'profile.php';
	$submenu['profile.php'][5] = array(__('Your Profile'), 'read', 'profile.php');
	if ( current_user_can('create_users') )
		$submenu['profile.php'][10] = array(__('Add New User'), 'create_users', 'user-new.php');
	else
		$submenu['profile.php'][10] = array(__('Add New User'), 'promote_users', 'user-new.php');
}

Исключая доступ пользователя к его пользовательскому профайлу, не забывайте о том, что такой пользователь не сможет вручную изменить свой пароль.

wp-admin/network/menu.php: Этот файл использоует право ‘read’ для того, что бы отображать или не отображать разделительную линию между разными меню администратора “Сеть”:

13
  $menu[4] = array( '', 'read', 'separator1', '', 'wp-menu-separator' );
69
  $menu[99] = array( '', 'read', 'separator-last', '', 'wp-menu-separator-last' );

Таким образом, право ‘read’ не выполняет в этом разделе никакой функции, обеспечивающей реальную безопасность или разделение прав.

wp-admin/mysites.php:Эта страница показывает отдельному пользователю все его сайты в данной сети. Также эта страница позволяет пользователю установить для себя главный (первичный) сайт. Пользователь может использовать ссылку под каждым из сайтов для их посещения, как домашней страницы, так и консоли выбранного сайта. Если у пользователя нет права ‘read’, доступ к этой странце запрещён.

15
16
if ( ! current_user_can('read') )
  wp_die( __( 'You do not have sufficient permissions to view this page.' ) );

wp-admin/includes/schema.php: Этот файл содержит код для создания права пользователя ‘read’. В строке 569 вы найдете функцию populate_roles_160():

564
565
566
567
568
569
/**
 * Create the roles for WordPress 2.0
 *
 * @since 2.0.0
 */
function populate_roles_160() {

с кодом в строке 610:

610
$role->add_cap('read');

который впервые, начиная с WordPress версии 2.0, наряду с другими вводит в действие право пользователя ‘read’.

Эта статься использует исходный код WordPress версии 3.5 RC2.

Tags: ,

  • Здравствуйте а вы не могли бы рассказать где в коде и в каких файлах можно прописать для пользователей разрешения редактировать закрепленные за ними страницы по ID страниц приэтом запретить доступ к другим страницам в админ панели. Возможно ли такое? и как это сделать?

  • вопрос снят я нашел на вашем блоге плагин то что надо.

  • imss

    Подскажите, не могу решить. Надо конкретный пост закрыть от редактирования всем кроме администратора. Как это сделать?