Конфиденциальность в WordPress или как работать с личными данными

Сегодня поговорим про конфиденциальность в WordPress при создании тем и плагинов, что это и зачем нужно. Вы пишете плагин, который обрабатывает личные данные — такие вещи, как имена, адреса и другие вещи, которые могут быть использованы для идентификации личности? Вы захотите позаботиться об этих данных и защитить конфиденциальность ваших пользователей и посетителей.

Конфиденциальность в WordPress © Из открытых источников
Конфиденциальность в WordPress © Из открытых источников

Что такое Конфиденциальность?

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

WordPress.org сделал несколько усовершенствований, опередив европейское Общее Положение о Защите Данных (GDPR, General Data Protection Regulation).

После начала этой работы они сделали конфиденциальность постоянным фокусом в развитии основных направлений, что позволит им продолжать вносить усовершенствования в конфиденциальность в WordPress для тем и плагинов, и защиты данных вне рамок конкретного законодательства.

Но какие вопросы могут подпадать под определение «конфиденциальности», и как мы это определяем?

Несмотря на то, что требования к конфиденциальности сильно различаются в разных странах, культурах и правовых системах, существует несколько общих принципов, применимых в любой ситуации:

  • Согласие и выбор: предоставление пользователям (и посетителям сайта) выбора и вариантов использования их данных, а также требование ясного, конкретного и информированного согласия;
  • Законность и спецификация цели: собирать и использовать персональные данные только в целях, для которых они предназначены, и для которых пользователь был заранее проинформирован;
  • Ограничение по сбору: собирайте только те данные пользователя, которые необходимы; не делайте дополнительных копий данных и не комбинируйте свои данные с данными из других плагинов, если вы можете этого избежать.
  • Минимизация данных: ограничить обработку данных, а также количество людей, имеющих к ним доступ, до минимума и людей, которые в ней нуждаются;
  • Ограничение использования, хранения и раскрытия: удаляйте данные, которые больше не нужны, как при активном использовании, так и в архивах, как получателем, так и любыми третьими лицами;
  • Точность и качество: убедитесь, что собранные и используемые данные являются правильными, релевантными и актуальными, особенно если неточные или недостоверные данные могут отрицательно повлиять на пользователя;
  • Открытость, прозрачность и уведомление: информируйте пользователей о том, как их данные собираются, используются и передаются, а также о любых правах, которые они имеют в отношении такого использования;
  • Индивидуальное участие и доступ: предоставить пользователям возможность доступа или скачивания своих данных;
  • Подотчетность: документирование использования данных, защита их при передаче и использовании третьими лицами, а также предотвращение неправомерного использования и нарушений в максимально возможной степени;
  • Информационная безопасность: защита данных путем принятия соответствующих технических мер и мер безопасности;
  • Соблюдение конфиденциальности: обеспечение соответствия работы правилам конфиденциальности того места, где она будет использоваться для сбора и обработки данных людей.

(Источник: ISO 29100/Privacy Framework standard)

Хотя не все из этих принципов будут применимы во всех ситуациях и областях применения, их использование в процессе разработки может помочь обеспечить доверие пользователей.

Конфиденциальность в дизайне

Многие из этих принципов соблюдаются в рамках концепции «Конфиденциальность в дизайне», которая гласит следующее:

  • Конфиденциальность в WordPress должна быть проактивной, а не реактивной, и должна предвосхищать вопросы конфиденциальности до того, как они дойдут до пользователя. Конфиденциальность также должна быть превентивной, а не корректирующей.
  • Конфиденциальность должна быть настройкой по умолчанию. Пользователь не должен предпринимать никаких действий для обеспечения своей конфиденциальности, и согласие на обмен данными не должно приниматься во внимание.
  • Конфиденциальность должна быть встроена в дизайн как основная функция, а не как дополнение.
  • Конфиденциальность должна быть положительной составляющей: не должно быть никаких компромиссов между конфиденциальностью и безопасностью, конфиденциальностью и надежностью, или конфиденциальностью и предоставлением услуг.
  • Конфиденциальность должна обеспечивать защиту в течение всего жизненного цикла за счет минимизации данных, минимального сохранения данных и регулярного удаления данных, в которых больше нет необходимости.
  • Стандарты конфиденциальности, используемые в Вашем плагине (и сервисе, если применимо) должны быть видимыми, прозрачными, открытыми, документированными и независимо проверяемыми.
  • Конфиденциальность должна быть ориентирована на пользователя. Людям должны быть предоставлены такие опции, как детальный выбор конфиденциальности, максимальная степень конфиденциальности по умолчанию, подробные уведомления о конфиденциальности, удобные для пользователя опции и четкое уведомление об изменениях.

Основные вопросы про конфиденциальность в WordPress

Чтобы помочь вашему плагину быть готовым, мы рекомендуем просмотреть следующий список вопросов для каждого плагина, который вы делаете:

1. Как Ваш плагин обрабатывает персональные данные? Используйте wp_add_privacy_policy_content(ссылка), чтобы раскрыть вашим пользователям следующее:

  • Предоставляет ли плагин личные данные третьим лицам (например, внешним API / серверам). Если да, какие данные он передает третьим сторонам и имеет ли они опубликованную политику конфиденциальности, на которую вы можете указать ссылку?
  • Собирает ли плагин личные данные? Если да, то какие данные и где они хранятся? Подумайте о таких местах, как пользовательские данные/мета, опции, почтовые мета-данные, пользовательские таблицы, файлы и т.д.
  • Использует ли плагин личные данные, собранные другими? Если да, то какие данные? Передает ли плагин персональные данные SDK? Что SDK делает с данными?
  • Плагин собирает данные телеметрии, прямо или косвенно? Например, загрузка изображения из стороннего источника при каждой установке может косвенно регистрировать и отслеживать данные об использовании всех установок вашего плагина.
  • Вызывает ли плагин Javascript, отслеживающие пиксели или встраиваемые iframe от третьей стороны (сторонние JS, отслеживающие пиксели и iframe могут собирать данные/действия посетителей, оставлять куки и т.д.)?
  • Хранит ли плагин что-то в браузере? Если да, то где и что? Подумайте о таких объектах, как файлы cookie, локальное хранилище и т.д.

2. Если Ваш плагин собирает личные данные…

  • Обеспечивает ли он экспорт персональных данных?
  • Предоставляет ли он обратный вызов для удаления личных данных?
  • По каким причинам (если таковые имеются) плагин отказывается удалять личные данные? (например, еще не выполненный заказ и т.д.) — эти данные также должны быть раскрыты.

3. Использует ли плагин протоколирование ошибок? Это позволяет избежать регистрации личных данных, если это возможно? Можете ли вы использовать, например, wp_privacy_anonymize_data, чтобы минимизировать зарегистрированные личные данные? Как долго хранятся записи в журнале? Кто имеет к ним доступ?

4. В wp-admin, какая роль/возможности необходимы для доступа/просмотра персональных данных? Достаточны ли они?

5. Какие персональные данные отображаются на фронтенде сайта с помощью плагина? Появляются ли они для пользователей, вошедших и вышедших из системы? Должны ли?

6. Какие персональные данные раскрываются плагином в конечных точках REST API? Появляются ли они для зарегистрированных и вышедших из системы пользователей? Какие роли/возможности необходимы, чтобы их увидеть? Являются ли они подходящими?

7. Правильно ли плагин удаляет/очищает данные, включая, в частности, личные данные:

  • Во время деинсталляции плагина?
  • Когда связанный элемент удаляется (например, из мета-данных записи или любых реферальных строк в другой таблице)?
  • Когда пользователь удаляется (например, из любой пользовательской строки в таблице)?

8. Предоставляет ли плагин элементы управления для уменьшения количества необходимых личных данных?

9. Разделяет ли плагин личные данные с SDK или API только тогда, когда SDK или API требует этого, или плагин также обменивается личными данными, которые являются необязательными?

10. Меняется ли количество личных данных, собираемых или передаваемых этим плагином, при установке некоторых других плагинов?

Эти вопросы про конфиденциальность в WordPress создатели CMS считают обязательными для владельцев сайтов и разработчиков.

Внешние ресурсы:

Содержание Политики Конфиденциальности

Предлагаемый текст для политики конфиденциальности сайта

Каждый модуль, который собирает, использует или хранит пользовательские данные, или передает их внешнему источнику или третьей стороне, должен добавлять раздел предлагаемого текста в почтовый ящик политики конфиденциальности.

Это лучше всего делать с помощью wp_add_privacy_policy_content( $plugin_name, $policy_text ). Это позволит администраторам сайта включить эту информацию в политику конфиденциальности своего сайта.

Чтобы сделать это проще для пользователей, текст должен отвечать на вопросы, предусмотренные политикой конфиденциальности по умолчанию:

  • Какие личные данные мы собираем и почему мы их собираем
    — Самостоятельно вводить информацию вручную
    — WP: Контактные формы
    — WP: Комментарии
    — WP: Куки-файлы
    — WP: Встраивания третьей стороны
    — Аналитика
  • С кем мы делимся вашими данными
  • Как долго мы храним ваши данные
  • Какие у вас есть права на ваши данные
  • Куда мы отправляем ваши данные
  • Ваши контактные данные
  • Как мы защищаем ваши данные
  • Какие процедуры по нарушению данных у нас есть
  • От каких третьих лиц мы получаем данные
  • Какие автоматические решения и/или профилирование мы делаем с данными пользователя
  • Любые требования по раскрытию информации, регулирующие отрасль

Хотя не все из этих вопросов применимы ко всем плагинам, мы рекомендуем обратить внимание на разделы об обмене данными.

Пример кода

Рекомендуется вызывать wp_add_privacy_policy_content во время действия (экшена) admin_init. Вызов его вне хука действия может привести к проблемам, подробности см. в тикете #44142.
Дополнительная информация может быть предоставлена с помощью специального CSS-класса .privacy-policy-tutorial. Любое содержимое, содержащееся в элементах HTML, к которым применен этот класс CSS, будет исключено из буфера обмена при копировании содержимого раздела.
function my_example_plugin_add_privacy_policy_content() {
if ( ! function_exists( 'wp_add_privacy_policy_content' ) ) {
return;
}
$content = '<p class="privacy-policy-tutorial">' . __( 'Some introductory content for the suggested text.', 'my_plugin_textdomain' ) . '</p>'
. '<strong class="privacy-policy-tutorial">' . __( 'Suggested Text:', 'my_plugin_textdomain' ) . '</strong> '
. sprintf(
__( 'When you leave a comment on this site, we send your name, email address, IP address and comment text to example.com. Example.com does not retain your personal data. The example.com privacy policy is <a href="%s" target="_blank">here</a>.', 'my_plugin_textdomain' ),
'https://example.com/privacy-policy'
);
wp_add_privacy_policy_content( 'Example Plugin', wp_kses_post( wpautop( $content, false ) ) );
}

add_action( 'admin_init', 'my_example_plugin_add_privacy_policy_content' );

Добавление Экспортера Личных Данных

В WordPress 4.9.6 были добавлены новые инструменты, облегчающие соблюдение таких законов, как Общее Положение Европейского Союза о Защите Данных, или сокращенно GDPR.

Среди инструментов, добавленных в WordPress 4.9.6, появился инструмент Экспорт Персональных Данных (Personal Data Export), который поддерживает экспорт всех персональных данных для данного пользователя в ZIP-файл.

В дополнение к персональным данным, хранящимся в таких объектах, как комментарии WordPress, плагины могут также подключаться к функции экспортера, чтобы экспортировать персональные данные, которые они собирают, будь то в нечто вроде postmeta или даже в совершенно новый Пользовательский Тип Данных (Custom Post Type, CPT).

«Ключом» для всех экспортируемых данных является адрес электронной почты пользователя — он был выбран потому, что поддерживает экспорт персональных данных как для полноправных зарегистрированных пользователей, так и для незарегистрированных (например, как комментатор, вышедший из системы).

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

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

После подтверждения запроса администратор может сгенерировать и скачать или отправить непосредственно по электронной почте ZIP-файл экспорта личных данных для пользователя, или сделать экспорт в любом случае, если возникает необходимость. Внутри ZIP-файла, который получает пользователь, он найдет «мини-сайт» с индексной HTML-страницей, содержащей его персональные данные, организованные в группы (например, группа для комментариев и т.д.).

Независимо от того, загружает ли администратор ZIP-файл экспорта персональных данных или отправляет его непосредственно запрашивающему лицу, способ сборки экспорта персональных данных идентичен — и полагается на перехват «экспортера» обратных вызовов для выполнения грязной работы по сбору всех данных для экспорта.

Когда администратор нажимает на ссылку загрузки или электронной почты, начинается цикл AJAX, который повторяется над всеми экспортерами, зарегистрированными в системе, по одному. В дополнение к экспортерам, встроенным в ядро, плагины могут регистрировать свои собственные обратные вызовы экспортеров.

Интерфейс обратного вызова экспортера разработан таким образом, чтобы быть как можно более простым. Обратный вызов экспортера получает адрес электронной почты, с которым мы работаем, а также параметр страницы. Параметр страницы (который начинается с 1) используется для того, чтобы избежать подключаемых модулей, которые могут вызвать таймауты при попытке экспортировать все личные данные, которые они собрали за один раз. Хорошо себя зарекомендовавший плагин ограничит количество данных, которые он пытается стереть на одной странице (например, 100 сообщений, 200 комментариев и т.д.).

Обратный вызов экспортера отвечает всеми данными, которые у него есть для этого адреса электронной почты и страницы, и независимо от того, сделано это или нет. Если обратный вызов экспортера сообщит о том, что это не было сделано, то он будет вызван снова (в отдельном запросе) с параметром страницы, увеличенным на 1. Ожидается, что обратный вызов экспортера вернет массив элементов для экспорта. Каждый элемент содержит идентификатор группы, для группы которой элемент является частью (например, комментарии, записи, заказы и т.д.), необязательной групповой меткой (translated), идентификатором элемента (например, comment-133), а затем массивом имен, пар значений, содержащим данные, которые должны быть экспортированы для этого элемента.

Примечательно, что значением может быть путь к медиафайлу, в этом случае ссылка на медиафайл будет добавлена в индексную HTML-страницу при экспорте.

Когда все экспортеры были вызваны для завершения, WordPress сначала собирает HTML-документ «index», который служит сердцем экспортного отчета. Если плагин сообщает дополнительные данные для элемента, который WordPress или другой плагин уже добавил, то все данные для этого элемента будут представлены вместе.

Экспорт кэшируется на сервере в течение 3 дней, а затем удаляется.

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

Во-первых, предположим, что плагин использовал add_comment_meta для добавления данных о местоположении, используя meta_key из latitude (широты) и longitude (долготы).

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

function my_plugin_exporter( $email_address, $page = 1 ) {
$number = 500; // Limit us to avoid timing out
$page = (int) $page;

$export_items = array();

$comments = get_comments(
array(
'author_email' => $email_address,
'number' => $number,
'paged' => $page,
'order_by' => 'comment_ID',
'order' => 'ASC',
)
);

foreach ( (array) $comments as $comment ) {
$latitude = get_comment_meta( $comment->comment_ID, 'latitude', true );
$longitude = get_comment_meta( $comment->comment_ID, 'longitude', true );

// Only add location data to the export if it is not empty
if ( ! empty( $latitude ) ) {
// Most item IDs should look like postType-postID
// If you don't have a post, comment or other ID to work with,
// use a unique value to avoid having this item's export
// combined in the final report with other items of the same id
$item_id = "comment-{$comment->comment_ID}";

// Core group IDs include 'comments', 'posts', etc.
// But you can add your own group IDs as needed
$group_id = 'comments';

// Optional group label. Core provides these for core groups.
// If you define your own group, the first exporter to
// include a label will be used as the group label in the
// final exported report
$group_label = __( 'Comments' );

// Plugins can add as many items in the item data array as they want
$data = array(
array(
'name' => __( 'Commenter Latitude' ),
'value' => $latitude
),
array(
'name' => __( 'Commenter Longitude' ),
'value' => $longitude
)
);

$export_items[] = array(
'group_id' => $group_id,
'group_label' => $group_label,
'item_id' => $item_id,
'data' => $data,
);
}
}

// Tell core if we have more comments to work on still
$done = count( $comments ) < $number;
return array(
'data' => $export_items,
'done' => $done,
);
}

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

При регистрации вы указываете дружественное имя для экспорта (для помощи в отладке — это дружественное имя в данный момент никому не показывается) и обратного вызова, например.

function register_my_plugin_exporter( $exporters ) {
$exporters['my-plugin-slug'] = array(
'exporter_friendly_name' => __( 'Comment Location Plugin' ),
'callback' => 'my_plugin_exporter',
);
return $exporters;
}

add_filter(
'wp_privacy_personal_data_exporters',
'register_my_plugin_exporter',
10
);

И это все! Теперь ваш плагин будет предоставлять данные для экспорта!

Добавление Стирателя личных данных к вашему плагину

В WordPress 4.9.6 были добавлены новые инструменты, облегчающие соблюдение таких законов, как Общее Положение Европейского Союза о Защите Данных, или сокращенно GDPR.

Среди инструментов, добавленных в WordPress 4.9.6, появился инструмент удаления личных данных (Personal Data Removal или Personal Data Eraser), который поддерживает удаление/анонимизацию личных данных для конкретного пользователя.

Он НЕ удаляет зарегистрированные учетные записи пользователей — это все еще отдельный шаг, который администратор может выбрать, делать это или нет.

В дополнение к личным данным, хранящимся в таких объектах, как комментарии WordPress, плагины могут также подключаться к стирателю, чтобы стереть личные данные, которые они собирают, будь то postmeta или даже в совершенно новых Пользовательских типах записей (Custom Post Type, CPT).

Как и в случае с экспортерами, «ключом» для всех ластиков является адрес электронной почты пользователя — он был выбран потому, что поддерживает стирание личных данных как для полноценных зарегистрированных пользователей, так и для незарегистрированных (например, как для комментатора, вышедшего из системы).

Однако, поскольку выполнение стирания личных данных является разрушительным процессом, мы не хотим просто сделать это без подтверждения запроса, поэтому пользовательский интерфейс, обращенный к администратору, начинает все запросы с того, что администратор вводит имя пользователя или адрес электронной почты, делая запрос, а затем посылает ссылку, нажав на которую, пользователь может подтвердить свой запрос. Как только запрос был подтвержден, администратор может начать стирание личных данных для пользователя, или заставить его, если необходимость возникает.

Способ стирания экспортируемых персональных данных аналогичен способу экспортеров персональных данных — и полагается на перехват «стирающих» обратных вызовов для выполнения грязной работы по стиранию данных. Когда администратор нажимает на ссылку удаления персональных данных, начинается цикл AJAX, который итературизирует все стиратели, зарегистрированные в системе, по очереди. В дополнение к стирателям, встроенным в ядро, плагины могут регистрировать свои собственные обратные вызовы стирателей.

Интерфейс обратного вызова стирателя разработан таким образом, чтобы быть как можно более простым. Обратный вызов стирателя получает адрес электронной почты, с которым мы работаем, а также параметр страницы. Параметр страницы (который начинается с 1) используется для того, чтобы избежать использования плагинов, которые могут вызывать таймауты, пытаясь стереть все личные данные, которые они собрали за один раз. Хорошо себя зарекомендовавший плагин ограничит количество данных, которые он пытается стереть на одной странице (например, 100 сообщений, 200 комментариев и т.д.).

Обратный вызов стирателя отвечает, были ли удалены элементы, содержащие личные данные, были ли сохранены какие-либо элементы, содержащие личные данные, массив сообщений для представления администратору (объясняя, почему элементы, которые были сохранены, были сохранены), и было ли это сделано или нет. Если обратный вызов стирателя сообщает, что это не было сделано, он будет вызван снова (в отдельном запросе) с параметром страницы, увеличенным на 1.

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

Поработаем над гипотетическим плагином, который добавляет к комментариям данные о местоположении комментатора. Предположим, что плагин использовал add_comment_meta для добавления данных о местоположении, используя meta_keys из latitude (широта) и longitude (долгота).

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

function my_plugin_eraser( $email_address, $page = 1 ) {
$number = 500; // Limit us to avoid timing out
$page = (int) $page;

$comments = get_comments(
array(
'author_email' => $email_address,
'number' => $number,
'paged' => $page,
'order_by' => 'comment_ID',
'order' => 'ASC',
)
);

$items_removed = false;

foreach ( (array) $comments as $comment ) {
$latitude = get_comment_meta( $comment->comment_ID, 'latitude', true );
$longitude = get_comment_meta( $comment->comment_ID, 'longitude', true );

if ( ! empty( $latitude ) ) {
delete_comment_meta( $comment->comment_ID, 'latitude' );
$items_removed = true;
}

if ( ! empty( $longitude ) ) {
delete_comment_meta( $comment->comment_ID, 'longitude' );
$items_removed = true;
}
}

// Tell core if we have more comments to work on still
$done = count( $comments ) < $number; return array( 'items_removed' => $items_removed,
'items_retained' => false, // always false in this example
'messages' => array(), // no messages in this example
'done' => $done,
);
}

Следующее, что должен сделать плагин, это зарегистрировать обратный вызов, отфильтровав массив стирателей с помощью фильтра wp_privacy_personal_data_erasers.

При регистрации вы предоставляете дружественное имя для стирателя (для помощи в отладке — это дружественное имя в данный момент никому не показывается) и обратного вызова, например:

function register_my_plugin_eraser( $erasers ) {
$erasers['my-plugin-slug'] = array(
'eraser_friendly_name' => __( 'Comment Location Plugin' ),
'callback' => 'my_plugin_eraser',
);
return $erasers;
}

add_filter(
'wp_privacy_personal_data_erasers',
'register_my_plugin_eraser',
10
);

И это все! Ваш плагин теперь очистит свои личные данные!

Опции, связанные с конфиденциальностью, Хуки и Возможности

Инструменты, что обеспечивают конфиденциальность в WordPress были первоначально представлены в версии 4.9.6.

Эти инструменты предназначены для того, чтобы позволить (и поощрить) разработчикам использовать их в рамках программ Экспорта Персональных Данных (Privacy Exporter), Стирания Персональных Данных (Privacy Eraser) и Руководства по политике конфиденциальности.

С тех пор было введено несколько новых хуков для расширения имеющихся возможностей. Эти хуки позволяют разработчикам включать дополнительные персональные данные в запросы на экспорт и стирание, а также знакомить с предлагаемым контентом для руководства по политике конфиденциальности.

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

Опции

wp_page_for_privacy_policy — содержит ID страницы конфиденциальности сайта

Действия (Экшены)

user_request_action_confirmed — срабатывает, когда пользователь подтверждает запрос конфиденциальности

wp_privacy_delete_old_export_files — запланированное действие, используемое для удаления старого экспорта из папки экспорта личных данных

wp_privacy_personal_data_erased — срабатывает после завершения последней страницы последнего стирателя

wp_privacy_personal_data_export_file — используется для создания файла экспорта личных данных в рамках процесса экспорта

wp_privacy_personal_data_export_file_created — срабатывает после создания файла экспорта персональных данных

Фильтры

privacy_policy_url — фильтрует URL страницы политики конфиденциальности

the_privacy_policy_link — фильтрует ссылку на страницу политики конфиденциальности HTML

wp_get_default_privacy_policy_content — фильтрует контент по умолчанию, предлагаемый для включения в руководстве по политике конфиденциальности

user_request_action_confirmed_message — позволяет изменять отображаемое пользователю сообщение с подтверждением действия

user_request_action_description — фильтрует описание действий пользователя

user_request_action_email_content — фильтрует текст сообщения электронной почты, отправленного при попытке действия учетной записи

user_request_action_email_headers — фильтрует заголовки письма, отправляемого при попытке действия учетной записи

user_request_action_email_subject — фильтрует тему письма, отправляемого при попытке действия учетной записи

user_request_confirmed_email_content — фильтрует тело письма с запросом подтверждения пользователя

user_request_confirmed_email_headers — фильтрует заголовки письма подтверждения запроса пользователя

user_request_confirmed_email_subject — фильтрует тему письма с запросом подтверждения пользователя

user_request_confirmed_email_to — фильтрует получателя уведомления о подтверждении запроса данных

user_request_key_expiration — фильтрует время истечения ключей подтверждения для пользовательских запросов

wp_privacy_additional_user_profile_data — фильтр для расширения данных профиля пользователя для экспортера конфиденциальности

wp_privacy_export_expiration — управляет разрешением получения старых файлов экспорта, по умолчанию — 3 дня

wp_privacy_personal_data_email_content — позволяет изменить сообщение электронной почты, отправляемое пользователям с помощью ссылки на файл экспорта их личных данных

wp_privacy_personal_data_email_headers — фильтрует заголовки письма, отправленного с файлом экспорта личных данных

wp_privacy_personal_data_email_subject — фильтрует тему письма, отправленного после завершения запроса на экспорт

wp_privacy_personal_data_email_to — фильтрует получателя уведомления по электронной почте экспорта личных данных

wp_privacy_personal_data_email_to следует использовать с большой осторожностью, чтобы не отправлять ссылку на экспорт данных на неправильный адрес (а) электронной почты получателя.

wp_privacy_personal_data_erasers — поддерживает регистрацию стирателей персональных данных ядра и плагина

wp_privacy_personal_data_erasure_page — фильтрует страницу данных стирателя личных данных. Позволяет использовать ответ на стирание адресатами в дополнение к Ajax.

wp_privacy_personal_data_exporters — поддерживает регистрацию экспортеров персональных данных ядра и плагинов

wp_privacy_personal_data_export_page — фильтрует страницу данных экспортера персональных данных. Используется для создания отчета об экспорте. Позволяет использовать экспортный ответ для пунктов назначения в дополнение к Ajax.

wp_privacy_anonymize_data — фильтрует анонимные данные для каждого типа

wp_privacy_exports_dir — фильтрует каталог, в котором хранятся файлы экспорта личных данных

wp_privacy_exports_url — фильтрует URL-адрес каталога, в котором хранятся файлы экспорта личных данных

user_confirmed_action_email_content — фильтрует текст письма с подтверждением запроса пользователя. Электронное письмо отправляется администратору после подтверждения запроса пользователя.

user_erasure_fulfillment_email_to — фильтрует получателя уведомления о выполнении стирания данных

user_erasure_complete_email_subject — фильтрует тему сообщения электронной почты, отправленного после завершения запроса на удаление

user_confirmed_action_email_content — фильтрует тело уведомления о выполнении стирания данных. Электронное письмо отправляется пользователю, когда администратор выполняет запрос на удаление данных.

user_erasure_complete_email_headers — фильтрует заголовки уведомления о выполнении стирания данных

Возможности

Доступ к инструментам обеспечения конфиденциальности контролируется несколькими новыми возможностями.

По умолчанию эти возможности есть у администраторов (на немультисайтовых установках).

Этими возможностями являются:

erase_others_personal_data — определяет, доступно ли подменю «Удалить личные данные» в разделе «Инструменты»

export_others_personal_data — определяет, доступно ли подменю «Экспорт личных данных» в разделе «Инструменты»

manage_privacy_options — определяет, доступно ли подменю Конфиденциальность в Настройках

На этом про конфиденциальность в WordPress всё. Я постараюсь дополнять данный материал по мере сил и возможностей.

Оригинал статьи
Опубликовано 13 февраля 2023 в 14:09
Обновлено 25 сентября 2023 в 01:30
Категория: Блог
Теги: