Spec-Zone .ru
спецификации, руководства, описания, API
|
Когда клиент соединяется с сервером MySQL, сервер использует имя пользователя, обеспеченное клиентом и хостом
клиента, чтобы выбрать соответствующую строку учетной записи из mysql.user
таблица.
Это тогда использует эту строку, чтобы аутентифицировать клиент.
В MySQL 5.7 сервер аутентифицирует клиенты, использующие плагины, следующим образом:
Сервер определяет от строки учетной записи, какой плагин аутентификации просит клиент:
Если строка учетной записи не определяет сменного имени, сервер
использует собственную аутентификацию; то есть, аутентификация против пароля, сохраненного в
Password
столбец строки учетной записи. Это - тот же самый
метод аутентификации, обеспеченный серверами MySQL, более старыми чем 5.5.7, прежде, чем
сменная аутентификация была реализована, но теперь реализуется, используя два плагина,
которые встраиваются и не могут быть отключены.
Если строка учетной записи определяет плагин, сервер вызывает ее, чтобы аутентифицировать пользователя. Если сервер не может найти плагин, ошибка происходит.
Плагин возвращает состояние серверу, указывающему, разрешают ли пользователю соединиться.
Сменная аутентификация включает двум важным возможностям:
Внешняя аутентификация: Сменная
аутентификация позволяет клиентам соединиться с сервером MySQL с учетными данными, которые являются
подходящими для методов аутентификации кроме собственной аутентификации, основанной на паролях,
сохраненных в mysql.user
таблица. Например, плагины могут быть созданы,
чтобы использовать внешние методы аутентификации, такие как ПЭМ, идентификаторы для входа в систему
Windows, LDAP, или Kerberos.
Пользователи прокси: Если пользователю разрешают соединиться, плагин аутентификации может возвратить серверу имя пользователя, отличающееся от имени соединяющегося пользователя, чтобы указать, что соединяющийся пользователь является прокси для другого пользователя. В то время как соединение длится, пользователь прокси обрабатывается, в целях управления доступом, как наличие полномочий различного пользователя. В действительности один пользователь исполняет роль другого. Для получения дополнительной информации см. Раздел 6.3.8, "Пользователи Прокси".
Несколько плагинов аутентификации доступны в MySQL. Следующие разделы обеспечивают детали об определенных плагинах.
Плагины, которые выполняют собственную аутентификацию, которая соответствует пароль
против Password
столбец строки учетной записи. См. Раздел
6.3.7.1, "Собственные Плагины Аутентификации". Собственная аутентификация является
значением по умолчанию для учетных записей, у которых нет никакого плагина, названного явно в их строке
учетной записи.
Плагин, который выполняет аутентификацию, используя SHA 256 хеширующих паролей.
Этот плагин соответствует пароль против authentication_string
столбец
строки учетной записи. Это - более сильное шифрование чем это доступное с собственной аутентификацией.
См. Раздел 6.3.7.2, "SHA 256 Плагинов
Аутентификации".
Клиентский плагин, который отправляет пароль серверу, не хешируя или шифрованию. Этот плагин может использоваться серверными плагинами, которые требуют доступа к паролю точно в соответствии с клиентским пользователем. См. Раздел 6.3.7.3, "Клиентский Плагин Аутентификации Открытого текста".
Плагин, который аутентифицирует клиенты, которые соединяются от локального узла до файла сокета Unix. См. Раздел 6.3.7.4, "Плагин Аутентификации Равноправных учетных данных Сокета".
Тестовый плагин, который аутентифицирует MySQL использования собственная аутентификация. Этот плагин предназначается в целях тестирования и разработки, и как пример того, как записать плагин аутентификации. См. Раздел 6.3.7.5, "Тестовый Плагин Аутентификации".
Для получения информации о текущих ограничениях на использование сменной аутентификации, включая который поддержка соединителей, который плагины, см. Раздел D.9, "Ограничения на Сменную Аутентификацию".
Сторонние разработчики соединителя должны считать тот раздел, чтобы определить степень, до которой соединитель может использовать в своих интересах сменные возможности аутентификации и что шаги взять, чтобы стать более совместимым.
Если Вам интересно в письменной форме Ваши собственные плагины аутентификации, см. Раздел 22.2.4.9, "Пишущий Плагины Аутентификации".
Вообще, сменная аутентификация использует соответствующие плагины на сторонах сервера и сторонах клиента, таким образом, Вы используете данный метод аутентификации как это:
На узле сервера установите соответствующую библиотеку, содержащую плагин сервера, в случае необходимости, так, чтобы сервер мог использовать это, чтобы аутентифицировать клиентские соединения. Точно так же на каждом хосте клиента, установите соответствующую библиотеку, содержащую клиентский плагин для использования клиентскими программами.
Создайте учетные записи MySQL, которые определяют использование плагина для аутентификации.
Когда клиент соединяется, плагин сервера говорит клиентскую программу который клиентский плагин использовать для аутентификации.
Остаток от этого раздела обеспечивает общие инструкции для установки и использования плагинов аутентификации. Инструкции используют плагин аутентификации в качестве примера, включенный в дистрибутивы MySQL (см. Раздел 6.3.7.5, "Тестовый Плагин Аутентификации"). Процедура подобна для других плагинов аутентификации; замените соответствующими сменными и именами файлов.
У плагина аутентификации в качестве примера есть эти характеристики:
Серверное имя плагина test_plugin_server
.
Клиентское имя плагина auth_test_plugin
.
Оба плагина располагаются в совместно используемом названном объектном файле
библиотеки auth_test_plugin.so
в сменном каталоге (каталог, названный plugin_dir
системная переменная). Суффикс имени файла мог бы разойтись в Вашей системе.
Установите и используйте плагин аутентификации в качестве примера следующим образом:
Удостоверьтесь, что сменная библиотека устанавливается на сервере и хостах клиента.
Установите серверный тестовый плагин при запуске сервера или во времени выполнения:
Чтобы установить плагин при запуске, используйте --plugin-load
опция. С этим загружающим плагин методом опция
должна быть дана каждый раз, когда Вы запускаете сервер. Например, используйте эти строки в
a my.cnf
файл опции:
[mysqld]plugin-load=test_plugin_server=auth_test_plugin.so
Чтобы установить плагин во времени выполнения, используйте INSTALL PLUGIN
оператор:
mysql> INSTALL PLUGIN
test_plugin_server SONAME 'auth_test_plugin.so';
Это устанавливает плагин постоянно и потребность быть сделанным только однажды.
Аутентификация ПЭМ, если не сделанная через пользователей прокси или группы, требует, чтобы у учетной записи MySQL было то же самое имя пользователя как учетная запись Unix. Поскольку имена пользователей MySQL ограничиваются 16 символами (см. Раздел 6.2.2, "Полномочие Систем Грант Тэбльз"), это ограничивает аутентификацию непрокси ПЭМ учетными записями Unix с именами самое большее 16 символов.
Проверьте, что плагин устанавливается. Например, использовать SHOW PLUGINS
:
mysql> SHOW PLUGINS\G
...*************************** 21. row *************************** Name: test_plugin_server Status: ACTIVE Type: AUTHENTICATIONLibrary: auth_test_plugin.soLicense: GPL
Для других способов проверить плагин, см. Раздел 5.1.8.2, "Получая информацию о Плагине Сервера".
Чтобы определить, что пользователь MySQL должен аутентифицироваться, используя
плагин, назовите его в IDENTIFIED WITH
пункт CREATE USER
оператор, который создает пользователя:
CREATE USER 'testuser'@'localhost' IDENTIFIED WITH test_plugin_server;
Соединитесь с сервером, используя клиентскую программу. Тестовый плагин
аутентифицирует тот же самый путь как собственная аутентификация MySQL, так что обеспечьте обычное --user
и
--password
опции, которые Вы обычно используете, чтобы соединиться с сервером. Например:
shell> mysql --user=your_name
--password=your_pass
Для соединений testuser
, сервер видит, что учетная запись должна
аутентифицироваться, используя серверный названный плагин test_plugin_server
и связывается с клиентской программой, какой
клиентский плагин это должно использовать — в этом случае, auth_test_plugin
.
В случае, что учетная запись использует метод аутентификации, который является значением по
умолчанию и для сервера и для клиентской программы, сервер не должен связаться с клиентом, какого
плагина использовать, и цикл обработки в клиент-серверном согласовании можно избежать. В настоящий
момент это - истина для учетных записей, которые используют собственную аутентификацию MySQL (mysql_native_password
).
--default-auth=
опция может быть определена на mysql командной строке, чтобы сделать явным,
какой клиентский плагин программа может ожидать использовать, хотя сервер переопределит это, если
учетная запись пользователя потребует различного плагина. plugin_name
Если mysql не находит плагин, определите a --plugin-dir=
опция, чтобы указать, где плагин
располагается.dir_name
Если Вы запускаете сервер с --skip-grant-tables
опция, плагины аутентификации не используются, даже если
загруженный, потому что сервер не выполняет аутентификации клиента и разрешает любому клиенту соединяться.
Поскольку это небезопасно, Вы могли бы хотеть использовать --skip-grant-tables
в соединении с --skip-networking
препятствовать тому, чтобы удаленные клиенты
соединились.