Пользователи в WordPress

Как работают права пользователя

• Роль - это набор capabilities
• У пользователя проверяются capabilities, а не название роли
• Capabilities роли не копируются в базу каждому пользователю

Как это хранится:

• Роли хранятся глобально в опции wp_user_roles.
  • В multisite роли хранятся отдельно для каждого сайта в опции {$wpdb->prefix}user_roles.
• У пользователя в wp_capabilities обычно хранятся только роли.
  • Там же могут храниться и индивидуальные capabilities, если они добавлены напрямую через WP_User::add_cap()

Пример wp_capabilities:

[
	'editor'        => true,
	'administrator' => true,
	'custom_cap'    => true,
]

Как WordPress определяет права:

1. В WP_User::get_role_caps():

   • берет capabilities всех ролей
   • добавляет индивидуальные capabilities
   • собирает итоговый набор в $this->allcaps

2. В WP_User::has_cap():

   • если это мета capability (не примитивное), сначала мапит его в примитивные
   • прогоняет $this->allcaps через фильтр user_has_cap
   • проверяет наличие указанной capability в $this->allcaps

Важно:

• Полный рассчитанный набор capabilities у пользователя в базе не хранится
• Он собирается динамически из ролей и user caps
• Если capability выдан напрямую пользователю, он уже хранится у самого пользователя

Связь такая:

• роль = шаблон прав
• пользователь = роли + возможно отдельные права
• итоговые права = объединение этого всего

Список Ролей

По умолчанию в WordPress 6 ролей:

Какую роль получает новый пользователь указывается в Настройки > Общие. Данные сохраняются в опции: users_can_register и default_role:

Список прав по ролям

Список примитивных (фундаментальных) прав пользователя. Это возможности которые по умолчанию есть у указанных ролей (пользователей).

Этот список прав задается единожды, при установке WordPress. Храниться в БД таблице wp_options в опции {$wpdb->prefix}_user_roles (wp_user_roles). Для мультисайта название этой опции будет иметь префикс таблиц WP, например wp_10_user_roles.

• ¹ — когда один сайт (не мультисайт).
• ² — когда один сайт (не мультисайт). Или включается в настройках сети.
• ³ — это право нужно включать отдельно, подробнее ниже.

Мета права

Выше перечислен список примитивных (фундаментальных) прав. Но есть еще так называемые мета-права. Они нигде не сохраняются, а вычисляются «налету» и в итоге превращаются в примитивное право.

Список мета-прав:

activate_plugin
activate_plugins
add_comment_meta
add_post_meta
add_term_meta
add_user_meta
add_users
assign_categories
assign_post_tags
assign_term
create_app_password
create_sites
create_users
customize
deactivate_plugin
deactivate_plugins
delete_app_password
delete_app_passwords
delete_categories
delete_comment_meta
delete_page
delete_plugins
delete_post
delete_post_meta
delete_post_tags
delete_site
delete_sites
delete_term
delete_term_meta
delete_themes
delete_user
delete_user_meta
delete_users
edit_app_password
edit_categories
edit_comment
edit_comment_meta
edit_css
edit_files
edit_page
edit_plugins
edit_post
edit_post_meta
edit_post_tags
edit_term
edit_term_meta
edit_themes
edit_user
edit_user_meta
edit_users
erase_others_personal_data
export_others_personal_data
install_languages
install_plugins
install_themes
list_app_passwords
manage_links
manage_network
manage_network_options
manage_network_plugins
manage_network_themes
manage_network_users
manage_post_tags
manage_privacy_options
manage_sites
promote_user
publish_post
read_app_password
read_page
read_post
remove_user
resume_plugin
resume_theme
setup_network
unfiltered_html
unfiltered_upload
update_core
update_https
update_languages
update_php
update_plugins
update_themes
upgrade_network
upload_plugins
upload_themes

edit_term                   — WP 4.7 — Не проверят кто создал термин - только проверяет наличие указанного термина и таксономии.
delete_term                 — WP 4.7 —
assign_term                 — WP 4.7 —
activate_plugin             — WP 4.9 — current_user_can( 'activate_plugin', 'my-plugin/my-plugin.php' )
deactivate_plugin           — WP 4.9 — current_user_can( 'deactivate_plugin', 'my-plugin/my-plugin.php' )

export_others_personal_data — WP 4.9.6 — is_multisite() ? 'manage_network' : 'manage_options'
erase_others_personal_data  — WP 4.9.6 — is_multisite() ? 'manage_network' : 'manage_options'
manage_privacy_options      — WP 4.9.6 — is_multisite() ? 'manage_network' : 'manage_options'

update_php                  — WP 5.0 — is_multisite() ? is_super_admin() : update_core
update_https                — WP 5.7 — is_multisite() ? is_super_admin() : manage_options | update_core

create_app_password         — WP 5.7 — map_meta_cap( 'edit_user', $user_id )
list_app_passwords          — WP 5.7 — map_meta_cap( 'edit_user', $user_id )
read_app_password           — WP 5.7 — map_meta_cap( 'edit_user', $user_id )
edit_app_password           — WP 5.7 — map_meta_cap( 'edit_user', $user_id )
delete_app_passwords        — WP 5.7 — map_meta_cap( 'edit_user', $user_id )
delete_app_password         — WP 5.7 — map_meta_cap( 'edit_user', $user_id )

Для проверки таких прав нужно передавать дополнительные параметры, например ID записи для которой нужно проверить может ли пользователь её редактировать. Например:

if( current_user_can( 'edit_post', 123 ) ){
	 echo 'Текущий пользователь может редактировать пост 123';
}

В этом, случае WP налету проверяет является ли пользователь автором этого поста, или у него есть примитивное право редактировать все посты. В результате, если проверка пройдена, это мета право превращается в аналогичное примитивное право, которое разрешает выполнять действие.

Подробнее о мета правах читайте в описании map_meta_cap().

Динамические права

Это права которые не хранятся в БД, а вычисляются налету по определенным условиям. Делается такое вычисление на хуке user_has_cap.

install_languages          — WP 4.9 — update_core  ||  install_plugins  ||  install_themes
resume_plugins             — WP 5.2 — activate_plugins
resume_themes              — WP 5.2 — switch_themes
view_site_health_checks    — WP 5.2 — install_plugins  &&  is_super_admin (multisite)

См. wp_maybe_grant_install_languages_cap()
См. wp_maybe_grant_resume_extensions_caps()
См. wp_maybe_grant_site_health_caps()

unfiltered_upload

По умолчанию возможность unfiltered_upload есть у администратора. Однако это право по умолчанию заблокировано, т.е. роли не пройдут проверку if( current_user_can('unfiltered_upload') ), несмотря на наличие у них такого права.

Чтобы право unfiltered_upload начало работать как ожидается, нужно в файле wp-config.php «включить» константу:

define( 'ALLOW_UNFILTERED_UPLOADS', true );

С определением этой константы роли имеющие право unfiltered_upload смогут загружать файлы с любым расширением (без проверки типа файла).

Для мультисайт сборки право unfiltered_upload есть только у Супер Администратора. Если у другой роли есть право unfiltered_upload, оно просто будет игнорироваться. Подробнее смотрите проверку мета-права в map_meta_cap():

case 'unfiltered_upload':
	if ( defined( 'ALLOW_UNFILTERED_UPLOADS' ) && ALLOW_UNFILTERED_UPLOADS && ( ! is_multisite() || is_super_admin( $user_id ) ) ) {
		$caps[] = $cap;
	} else {
		$caps[] = 'do_not_allow';
	}
	break;