Access to this page has been denied.
You have been blocked because we believe you are using automation tools to browse the website.
This may happen as a result of the following:
- Javascript is disabled or blocked by an extension (ad blockers for example)
- Your browser does not support cookies
If you think you have been blocked by mistake, please contact help@drupal.org with the reference ID below.
Reference ID: #8bb40c7d-872e-11ee-a17d-b3a688f9dc77
Powered by PerimeterX , Inc.
Как удалить или переместить учетную запись пользователя MySQL / MariaDB
Я создал учетную запись пользователя MySQL / MariaDB, используя эту страницу. Теперь я удалил свой блог WordPress, и я хочу удалить эту учетную запись пользователя, включая базу данных. Как удалить или перенести учетную запись пользователя MySQL или MariaDB в Linux или Unix-подобной системе, используя опцию командной строки mysql?
MySQL и MariaDB — системы управления базами данных с открытым исходным кодом. В этом кратком руководстве вы узнаете:
Как удалить или переместить учетную запись пользователя в базе данных MySQL или MariaDB в Linux или Unix-подобной системе
Предупреждение! Создайте резервную копию своей базы данных, прежде чем вводить одну из следующих команд.
Шаг 1 – Шаги по удалению пользователя MySQL/MariaDB
Если вы решили удалить приложение с открытым исходным кодом, такое как WordPress или Drupal, вам нужно удалить эту учетную запись пользователя. Вам нужно удалить все разрешения / свойства и удалить пользователя из таблицы MySQL. Сначала войдите в систему как пользователь MySQL mysql на сервер MySQL / MariaDB, используя оболочку, запустите:
$ mysql -u root -p mysql
$ mysql -u root -h server-name-here -p mysql
Примеры возможных выводов данных:
Шаг 2 –Перечислите всех mysql пользователей
Когда у вас есть приглашение MySQL или MariaDB, которое выглядит почти точно также, как и на рисунке 1, введите следующую команду в приглашении mysql> или mariadb>, чтобы просмотреть список пользователей MySQL / MariaDB
mariadb> SELECT User,Host FROM mysql.user;
Примеры возможных выводов данных:
В данном примере, мне нужно удалить mysql пользователя с именем ‘bloguser’@’localhost’ .
Шаг 3 – Список свойств для пользователя mysql
Для того, чтобы посмотреть какими свойствами обладает bloguser, введите:
mariadb> SHOW GRANTS FOR 'bloguser'@'localhost';
Примеры возможных выводов данных:
- bloguser – Mysql/Maridb имя пользователя
- localhost – Mysql/Mariadb имя хоста
- mywpblog – имя базы данных
Шаг 4 – Отменить все свойства для пользователя mysql
Введите следующую sql команду:
mariadb> REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'bloguser'@'localhost';
Примеры возможных выводов данных:
Query OK, 0 rows affected (0.00 sec)
Шаг 5 – Переместить/Удалить пользователя из таблицы пользователей
Введите следующую sql команду:
mariadb> DROP USER 'bloguser'@'localhost';
Примеры возможных выводов данных:
Query OK, 0 rows affected (0.00 sec)
Шаг 6 – Удаление базы данных
Введите следующую команду:
mariadb> DROP DATABASE mywpblog;
Примеры возможных выводов данных:
Query OK, 0 rows affected (0.00 sec)
И, наконец, вы справились. Пользователь MySQL/MariaDB удаляется или перемещается с сервера в Unix или Linux через опцию командной строки.
Это интересно:
- Установка и настройка Apache, PHP, MySQL, phpMyAdmin на Linux (LAMP)
- Установка и настройка сервера Apache, PHP, MySQL, phpMyAdmin на Windows 10
- Установка Adobe Photoshop CS6 на Linux (очень простой способ)
Оставить ответ Отменить ответ
�� С 20 по 22 апреля пройдут незабываемые битвы среди кибер-гладиаторов в мире информационной безопасности!
Открыта регистрация команд по ссылке .
Drupal 8: Сервис user.data — хранилище данных пользователей
user.data — сервис, который добавляет хранилище где можно хранить какие-угодно данные пользователей.
Данный сервис очень похож по своему принципу и работе на State API, с тем отличием, что он больше заточен под хранение данных для пользователя и тесно связан с ними.
Может возникнуть резонный вопрос, а зачем этот сервис, когда есть State API, темболее, если их принцип работы практически не отличается:
- Сервис user.data предназначен для хранения данных пользователей, тогда как State API является хранилищем общего назначения.
- Если вы желаете сохранить какие-то данные привязанные к конкретному пользователю, значит вам, скорее всего, нужен user.data, нежели State API. Так вам не придется выдумывать ключи и заботиться об их удалении в дальнейшем.
- user.data чистит хранилище пользователя, при его удалении, так у вас не останутся неиспользуемые данные в БД, и вам не нужно об этом даже думать.
Резюмируя: используйте user.data, если хотите хранить данные с привязкой к пользователю по его UID, в иных случаях используйте State API.
Также стоит отметить то, что использование user.data в некоторых случаях не только перекрывает необходимость использования полей, но даже имеет ряд преимуществ над ними. А именно — user.data не модифицирует сущность пользователя , тем самым, сохраняя данные в user.data, вы не запускаете процесс сохранения сущности, который производит инвалидацию кэш-тегов, а они, в свою очередь, инвалидируют все данные, которые так или иначе связаны с пользователем.
Таким образом, user.data более благоприятный инструмент для производительности сайта, так как не будет инвалидировать кэш. Вероятнее всего, данные что вы будете в нем хранить и не должны его инвалидировать. Этот сервис идеальное решение для хранения настроек пользователя.
В Drupal данный сервис используется лишь одним единственным модулем — contact. При его активации он сохраняет настройки персональных контактных форм для каждого пользователя в данное хранилище, не создавая для этого отдельное поле, и не используя State API.
Структура UserData ¶
В данном разделе мы разберемся со всеми методами данного сервиса.
set() ¶
Метод set() отвечает за сохранения определенного значения в хранилище. Он принимает следующие обязательные аргументы:
- $module : Машинное название модуля, который сохраняет настройки в хранилище.
- $uid : Идентификатор пользователя, которому принадлежит сохраняемое значение.
- $name : Машинное название для сохраняемой настроки. Иными словами — ключ.
- $value : Любое значение, которое вы хотите сохранить.
$user_data = \Drupal::service('user.data'); $user_data->set('my_module', 1, 'key', [ 'some' => 'value', 'foo' => 'bar', ]); get() ¶
Метод get() отвечает за получение данных из хранилища.
Принимает следующие аргументы:
- $module : Машинное название модуля, чьи данные необходимо получить.
- $uid : (опционально) Идентификатор пользователя, данный которого необходимо получить.
- $name : (опционально) Машинное название настройки, значение которого необходимо получить.
Обратите внимание на то, что лишь $module является обязательным аргументом. В зависимости от того, как вы укажите $uid и $name можно добиться различных результатов.
$user_data = \Drupal::service('user.data'); // Gets value stored by "my_module" for user 1 in key "key". $value = $user_data->get('my_module', 1, 'key'); // Gets array "key => value" stored by "my_module" for user 1. $value = $user_data->get('my_module', 1); // Gets array "uid => value" stored by "my_module" in key "key" for all // users which has value in storage. $value = $user_data->get('my_module', NULL, 'key'); // Gets array of arrays "uid => [key => value, . ]" stored by // "my_module" for every user and key. $value = $user_data->get('my_module'); delete() ¶
Метод delete() отвечает за удаление данных из хранилища.
Он принимает следующие аргументы:
- $module : (опционально) Машинное имя модуля, чьи данные необходимо удалить.
- $uid : (опционально) Идентификатор пользователя, чьи данные нужно удалить.
- $name : (опционально) Название ключа, данные в котором необходимо удалить.
Данные аргументы являются опциональными, поэтому будьте аккуратны, так как вызов метода без передачи аргумнетов, удалит все данные, всех модулей, для всех пользователей безвозвратно.
Любой из данных аргументов может быть как точным значением, так и массивом значений.
Также, обратите внимание на то, что вам не нужно беспокоиться об удалении данных при удалении пользователя, это будет сделано автоматически, но при этом, вам необходимо заботиться об удалении данных из хранилища, при удалении вашего модуля.
$user_data = \Drupal::service('user.data'); // Deletes all data for all users and modules. $user_data->delete(); // Deletes all data for all user stored by module "my_module". $user_data->delete('my_module'); // Deletes all data for all users stored by modules "my_module" and // "my_second_module". $user_data->delete(['my_module', 'my_second_module']); // Deletes all data for user 1. $user_data->delete(NULL, 1); // Deletes all data for users 1, 2 and 3. $user_data->delete(NULL, [1, 2, 3]); // Deletes all data for all users of any module which has key "key". $user_data->delete(NULL, NULL, 'key'); // C-c-c-combo! // Deletes values stored in keys "key" and "second_key" for users 1, 2 // and 3 by modules "my_modyle" and "my_second_module". $modules = ['my_module', 'my_second_module']; $uids = [1, 2, 3]; $keys = ['key', 'second_key']; $user_data->delete($modules, $uids, $keys); Пример ¶
В материале про создание Authentication Provider в примере мы сделали базовые поля для хранения API key и API secret у пользователя, где мне и указали (спасибо andypost), что есть данный сервис и лучше эти данные хранить именно в нем. Это намного легче и не будет вызывать ненужных инвалидаций кэша.
Мы сделаем модуль, который будет хранить API key и API secret в user.data хранилище, выводить их в форме пользователя, и удалять, при деинсталяции модуля.
Первым делом мы создадим в модуле инсталяционный файл dummy.install и напишем в нем логику генерации ключей для всех пользователей, а также удаление данных при деинсталяции модуля.
dummy.install
execute(); foreach ($users as $uid) < $api_key = Crypt::randomBytesBase64(16); $api_secret = Crypt::randomBytesBase64(16); $user_data->set('dummy', $uid, 'api_key', $api_key); $user_data->set('dummy', $uid, 'api_secret', $api_secret); > > /** * Implements hook_uninstall(). */ function dummy_uninstall() < $user_data = Drupal::service('user.data'); // Delete all data for current module. $user_data->delete('dummy'); > В dummy_install() мы загружаем всех пользователей, проходимся по каждому из них, генерируем значение для ключа и секрета, а затем сохраняем эти значения для конкретного пользователя в user.data хранилище, указывая названия нашего модуля и ключи данных.
В dummy_uninstall() мы удаляем вообще все данные что наш модуль мог бы сохранить. Так мы не оставим за собой мертвых данных. А удалением данных при удалении пользователя будет заниматься сущность пользователя самостоятельно.
Обратите внимание что это не очень хороший для производительности пример. Он лишь показыает общий принцип работы. Генерировать и сохранять ключи прямо при установке плохая идея, так как пользователей может быть очень много. Если необходимо генерировать каждому пользователю эти данные сразу, не по запросу самого пользователя, лучше всего воспользоваться Queue API в связке с QueueWorker, тем самым разгрузив процесс включения модуля, а также исключить падение от нехватки ресурсов или различных лимитов.
Нам также необходимо выводить эту информацию в форме редактирования пользователя, а также предусмотреть генерацию ключа и секрета при создании новых пользователей.
dummy.module
set('dummy', $entity->id(), 'api_key', $api_key); $user_data->set('dummy', $entity->id(), 'api_secret', $api_secret); > /** * Implements hook_form_FORM_ID_alter(). */ function dummy_form_user_form_alter(array &$form, FormStateInterface $form_state, $form_id) < $profile = $form_state->getFormObject(); if ($profile instanceof ProfileForm) < $user_data = Drupal::service('user.data'); /** @var \Drupal\user\UserInterface $user */ $user = $profile->getEntity(); $form['dummy_api'] = [ '#type' => 'fieldset', '#title' => 'API', ]; $form['dummy_api']['key'] = [ '#type' => 'item', '#title' => 'Key', '#markup' => $user_data->get('dummy', $user->id(), 'api_key'), ]; $form['dummy_api']['secret'] = [ '#type' => 'item', '#title' => 'Secret', '#markup' => $user_data->get('dummy', $user->id(), 'api_secret'), ]; > > В хуке dummy_user_insert() мы отлавливаем создание новых пользователей на сайте и сразу же генерируем для них ключ и секрет, сохраняя в хранилище по принципу dummy_install() .
В хуке dummy_form_user_form_alter() мы подключаемся к форме редактирования пользователя, получаем объект пользователя, кому принадлежит данная форма, и описываем элементы форм, которые будут выводить наши значения.
Если включить модуль, все пользователи получать свои уникальные ключи и секреты, и при редактировании своих профилей будут видеть соответствующий раздел в форме.
Drupal → Как удалить все материалы определённого типа
Как поведут себя коментарии к этим нодам в такой ситуации ?
удалятся, как и файлы, синонимы и т.п.
А не подскажете, как можно сделать, чтобы ноды с определенными nid нельзя было удалить из админки ?
Например, есть какие-то ключевые ноды и чтобы пользователь по глупости их не удалил.
Смущает то, что если у владельца сайта будет доступ к логину администратора (uid=1), а он имеет на это право, то этот хук, как Вы сами пишите, не сработает.
Возможно ли, чтобы, к примеру, если нужно запретить удаление нод с nid 30 и 35, то просто перехватить команды меню ‘node/30/delete’ и ‘node/35/delete’, чтобы они не выполнялись? То есть, добавить исключения к команде ‘node/*/delete’.
Есть ли такие возможности ?
если у рут-админа есть желание что-то удалить с сайта, то ни один модуль не сможет ему в этом помешать 😉 поэтому не давайте владельцу сайта данные от главного админа
То есть, создать ему аккаунт с uid=2 и пусть оттуда работает .
Так а вот чисто теоретический вопрос задам, если не возражаете .
Есть ли возможность добавлять исключения к меню с %-символами ? Не было ли у Вас на эту тему поста ?
что за исключения к меню?
Ну, допустим, есть команда меню, прописанная в таблице menu_router как ‘node/%/delete’. И при её вызове отрабатывает функция, которая осуществляет удаление ноды.
А как и что нужно сделать, чтобы, команды node/30/delete и node/35/delete обрабатывались как-то иначе , чем стандартная команда node/%/delete ?
То есть, если значения аргумента % равны 30 или 35, то обработчик будет другим — например, дополнять стандартную обработку, либо изменять её, либо вообще ничего не делать.
Если в базе будет десятки тысяч записей и за 600 секунд не успеет всё удалиться, ничего не случится? Можно повторно будет выполнять скрипт пока вся база не очиститься?
можно, но лучше пользуйтесь views bulk operations
При удалении появляется ошибка PDOException Object ERROR: null value in column «node_title» violates not-null constraint
Зашел в эти ноды, у них заголовок пустой. База древняя, всё могло быть.
Вопрос, как принудительно сказать друпалу, чтобы их всё равно удалял?