Авторизация php mysql сессии: Авторизация, сессии (php, mysql)? — Хабр Q&A

Авторизация, сессии (php, mysql)? — Хабр Q&A

Всё можно подменить, если вы ЭЦП не используете. Если боитесь подбора чужого session ID — то нужно этот самый ID сделать длинным, 64 байта например. Если основные опасения — что у пользователя уведут куки с его session ID, то проверяйте user-agent, разрешение экрана, версию flash.

Ответ написан

более трёх лет назад

Вот кое что нашел, возможно пригодится:
habrahabr.ru/blogs/php/13726/
php.ru/forum/viewtopic.php?t=15658

Ответ написан

более трёх лет назад

Комментировать

>а благодаря таблице sessions не храним в куках пароль.

рыдалЪ

Ответ написан

более трёх лет назад

Все что угодно можно подменить. Советую не быть крайне параноиком в этом плане.

Товарищи выше дают крайне полезный совет. Браузер + IP. В другом браузере все равно заново логиниться, а чтобы проще это распознавать, то используйте хэш. md5([browser].[IP])

Ответ написан

более трёх лет назад

Комментировать

Почему бы не посмотреть как сделано в vbulletin, invision или просто какой-нибудь хорошей CMS? Задача авторизации это реально такой баянистый велосипед… заодно подсмотрите всякие интересные штуки типа индивидуальной соли паролей, логин с запоминанием или без, серверную авторизацию как опцию и http only печеньки и прочее и прочее.

Ответ написан

более трёх лет назад

Привязка по ип, а также сверять, что в базе, и что в самих куках

Ответ написан

более трёх лет назад

Делать сессию с привязкой по данным, снимаемым с пользователя, самое популярное — ip адрес, браузер, куки.

Ответ написан

более трёх лет назад

Комментировать

Можно привязать ее IP.

Вообще, примеров по этому поводу в гуле вагон и маленькая тележка 🙂

Ответ написан

2012, в 20:29″>
более трёх лет назад

По ip привязывать как-то не хочется. А вдруг динамичный ip.

Единственное, сверять user agent браузера. Больше ничего в голову не лезит )

Ответ написан

более трёх лет назад

Комментировать

Лучше всего вам разобраться как например сделаны сессии в том же PHP по умолчанию. Касательно вопроса (session_id хранится в куках, его можно подменить) — а вы делайте этоот session_id из 32-64 букв, знаков и цифр. Подменить-то такой ид можно, но сначала надо его подобрать, а это годы работу суперкомпьюетров.

Ответ написан

более трёх лет назад

Имхо, стоит сначала определиться:

1) будут ли подменять сессию 90% пользователей?

2) будут ли подделывать useragent те же самые 90%?

Если нет — не стоит задачу усложнять 😉 ИМХО.

Ответ написан

более трёх лет назад

Комментировать

Как правильно сделать авторизацию на php?

Например я хочу чтобы пользователь авторизовался в игре и у него открылась сессия. Если он закроет страницу и зайдет на эту страницу через день, то сессия сохранится? Или это надо делать как-то с куки и базой данных?

1

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

зайдет на эту страницу через день, то сессия сохранится?

Время жизни сессии настраивается в параметре gc_maxlifetime в файле php.ini, но, как правило, запоминание пользователя реализуется через cookie, которому можно указать произвольное время, в течение которого cookie будет действительным.

Вообще ваш вопрос довольно общий, поэтому сложно посоветовать что-то конкретное. Смотрите примеры авторизации в интернете и документацию:

• HTTP cookies,
• работа с сессиями.

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

Сохранить эти данные вы можете на свое усмотрение, в cookies, в массиве сессий $_SESSION или в локальном хранилище, называемом localStorage.

Суть будет одна и та же, данные от пользователя, хранящиеся в его браузере вы должны проверить со своими, которые получаете чаще всего из базы данных. Если данные валидны и совпали, сессия живет, пользователь авторизован.

Что именно использовать в качестве хранилища на клиенте, решать только вам, при необходимости устанавливать время протухания сессии, а еще и для разных роутов или уровней доступа, чаще всего используют куки, для их установки и отправки реализована специальная функция (https://www.php.net/manual/ru/function.setcookie.php) в языке.

Однако, глобальный массив $_SESSION, зачастую вызывает у новичков меньше вопросов и приводит к меньшему количеству проблем, т.к. используется он как самый простой массив доступный из любого места в скрипте.

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

MySQL :: Справочное руководство по MySQL 8.

0 :: 6.2.17 Подключаемая аутентификация

6.2.17 Подключаемая аутентификация

Когда клиент подключается к серверу MySQL, сервер использует
имя пользователя, предоставленное клиентом и хостом клиента, чтобы выбрать
соответствующая строка учетной записи из mysql.user
системная таблица. Затем сервер аутентифицирует клиента,
определение из строки учетной записи, какой плагин аутентификации
относится к клиенту:

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

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

Подключаемая аутентификация обеспечивает следующие важные возможности:

• Выбор методов аутентификации.
  Подключаемая аутентификация упрощает выбор для администраторов баз данных.
  и изменить метод аутентификации, используемый для отдельных
  Учетные записи MySQL.

• Внешняя аутентификация.
  Подключаемая аутентификация позволяет клиентам
  подключиться к серверу MySQL с учетными данными, подходящими для
  методы аутентификации, которые хранят учетные данные в другом месте, кроме
  в mysql.user системная таблица. За
  например, плагины могут быть созданы для использования внешних
  методы аутентификации, такие как PAM, идентификаторы входа в систему Windows, LDAP,
  или Керберос.

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

Примечание

Если вы запускаете сервер с
--skip-grant-tables опция,
плагины аутентификации не используются, даже если они загружены, потому что
сервер не выполняет аутентификацию клиента и разрешает любому клиенту
подключить. Потому что это небезопасно, если сервер запущен
с --skip-grant-tables
вариант, он также отключает удаленные подключения, включив
пропуск_сети .

• Available Authentication Plugins

• The Default Authentication Plugin

• Authentication Plugin Usage

• Authentication Plugin Client/Server Compatibility

• Authentication Plugin Connector-Writing Considerations

• Restrictions on Pluggable Authentication

Доступные модули аутентификации

MySQL 8. 0 предоставляет следующие подключаемые модули аутентификации:

• Плагин, выполняющий встроенную аутентификацию; то есть,
  аутентификация на основе используемого метода хеширования пароля
  до введения подключаемой аутентификации в
  MySQL. Плагин mysql_native_password
  реализует аутентификацию на основе этого собственного пароля
  метод хеширования. Видеть
  Раздел 6.4.1.1, «Встроенная подключаемая аутентификация».

• Плагины, выполняющие аутентификацию с использованием пароля SHA-256.
  хеширование. Это более сильное шифрование, чем доступное
  с собственной аутентификацией. Видеть
  Раздел 6.4.1.2, «Кэширование подключаемой аутентификации SHA-2» и
  Раздел 6.4.1.3, «Подключаемая аутентификация SHA-256».

• Клиентский плагин, который отправляет пароль на сервер
  без хеширования и шифрования. Этот плагин используется в
  в сочетании с серверными плагинами, которым требуется доступ к
  пароль точно такой же, как предоставленный пользователем клиента. Видеть
  Раздел 6.4.1.4, «Подключаемая аутентификация открытым текстом на стороне клиента».

• Плагин, выполняющий внешнюю аутентификацию с использованием PAM.
  (Подключаемые модули аутентификации), позволяющие серверу MySQL
  использовать PAM для аутентификации пользователей MySQL. Этот плагин поддерживает
  также пользователи прокси. Видеть
  Раздел 6.4.1.5, «Подключаемая аутентификация PAM».

• Плагин, который выполняет внешнюю аутентификацию в Windows,
  позволяя MySQL Server использовать собственные службы Windows для
  аутентифицировать клиентские соединения. Пользователи, вошедшие в
  Windows может подключаться из клиентских программ MySQL к серверу
  на основе информации в их среде без
  указание дополнительного пароля. Этот плагин поддерживает
  также пользователи прокси. Видеть
  Раздел 6.4.1.6, «Подключаемая аутентификация Windows».

• Плагины, выполняющие аутентификацию с использованием LDAP (облегченный
  Протокол доступа к каталогам) для аутентификации пользователей MySQL с помощью
  доступ к службам каталогов, таким как X.500. Эти плагины
  поддержка пользователей прокси, а также. Видеть
  Раздел 6.4.1.7, «Подключаемая аутентификация LDAP».

• Плагин, который выполняет аутентификацию с использованием Kerberos для
  аутентифицировать пользователей MySQL, которые соответствуют Kerberos
  принципы. Видеть
  Раздел 6.4.1.8, «Подключаемая аутентификация Kerberos».

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

• Плагин, который аутентифицирует клиентов, которые подключаются из
  локальный хост через файл сокета Unix. Видеть
  Раздел 6.4.1.10, «Подключаемая аутентификация через одноранговые учетные данные сокета».

• Плагин, который аутентифицирует пользователей на сервере MySQL с использованием FIDO.
  аутентификация. Видеть
  Раздел 6.4.1.11, «Подключаемая аутентификация FIDO».

• Тестовый плагин, который проверяет учетные данные и журналы
  успех или неудача в журнале ошибок сервера. Этот плагин
  предназначены для тестирования и разработки, а также в качестве
  пример того, как написать плагин аутентификации. Видеть
  Раздел 6.4.1.12, «Проверка подключаемой аутентификации».

Примечание

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

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

Если вы заинтересованы в написании собственной аутентификации
плагины, см. Написание плагинов аутентификации.

Плагин аутентификации по умолчанию

CREATE USER и
Операторы ALTER USER имеют синтаксис
для указания способа аутентификации учетной записи. Некоторые формы этого
синтаксис не указывает явным образом подключаемый модуль аутентификации (существует
пункт IDENTIFIED WITH ). Например:

 СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ 'jeffrey'@'localhost' ИДЕНТИФИЦИРОВАННОГО ' паролем '; 

В таких случаях сервер назначает аутентификацию по умолчанию
плагин к аккаунту. До MySQL 8.0.27 это значение по умолчанию
стоимость
default_authentication_plugin
системная переменная.

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

• Фактор 1: если
  аутентификация_политика
  элемент 1 называет подключаемый модуль аутентификации, этот подключаемый модуль является
  дефолт. Если
  аутентификация_политика
  элемент 1 равен * , значение
  default_authentication_plugin
  по умолчанию.

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

   СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ 'wei'@'localhost' ИДЕНТИФИЦИРОВАННЫЙ ' пароль '
    И ИДЕНТИФИКАЦИЯ С помощью authentication_ldap_simple; 

  Точно так же этот пример создает трехфакторную
  учетная запись аутентификации:

   СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ 'mateo'@'localhost' ИДЕНТИФИКАЦИЯ ' пароль '
    И ИДЕНТИФИКАЦИЯ С помощью authentication_ldap_simple
    И ИДЕНТИФИЦИРОВАНО С помощью authentication_fido; 

  Вы можете использовать SHOW CREATE USER
  для просмотра применяемых методов аутентификации.

• Фактор 2 или 3: если соответствующий
  аутентификация_политика
  элемент называет подключаемый модуль аутентификации, этот подключаемый модуль является
  дефолт. Если
  аутентификация_политика
  элемент * или пустой, нет
  дефолт; попытка определить аутентификацию учетной записи
  метод для фактора без указания плагина является ошибкой,
  как в следующих примерах:

   mysql> СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ 'sofia'@'localhost', ИДЕНТИФИЦИРОВАННОГО С помощью authentication_ldap_simple
         И ОПОЗНАЕТСЯ 'abc';
  ОШИБКА 1524 (HY000): Плагин '' не загружен
  mysql> СОЗДАЙТЕ ПОЛЬЗОВАТЕЛЯ 'sofia'@'localhost', ИДЕНТИФИЦИРОВАННОГО С помощью authentication_ldap_simple
         И ОПОЗНАЕТСЯ 'abc';
  ОШИБКА 1524 (HY000): Плагин '*' не загружен 

Использование плагина аутентификации

В этом разделе приведены общие инструкции по установке и
с помощью плагинов аутентификации. Для инструкций, специфичных для
данного плагина, см. раздел, описывающий этот плагин, в разделе
Раздел 6.4.1, «Плагины аутентификации».

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

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

• Для каждой создаваемой учетной записи MySQL укажите
  соответствующий серверный плагин для аутентификации. Если
  учетная запись должна использовать подключаемый модуль аутентификации по умолчанию,
  в заявлении о создании учетной записи не нужно указывать плагин
  явно. Сервер назначает аутентификацию по умолчанию
  плагин, определяемый, как описано в
  Плагин аутентификации по умолчанию.

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

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

Для стандартных клиентов MySQL, таких как , mysql и
mysqladmin ,
--default-auth= имя_плагина
опция может быть указана в командной строке как подсказка о
какой клиентский плагин программа может использовать, хотя
сервер переопределяет это, если подключаемый модуль на стороне сервера связан
с учетной записью пользователя требуется другой подключаемый модуль на стороне клиента.

Если клиентская программа не находит подключаемый модуль на стороне клиента
файл библиотеки, укажите
--plugin-dir= имя_каталога
опция, указывающая расположение каталога библиотеки плагинов.

Подключаемый модуль аутентификации Совместимость клиент/сервер

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

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

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

• Подключитесь с помощью клиента MySQL 5.7 версии 5.7.22 или ниже к
  Учетная запись сервера MySQL 8.0, которая аутентифицируется с помощью
  caching_sha2_password . Это не удается, потому что
  клиент 5.7 не распознает плагин, который был
  введен в MySQL 8.0. (Эта проблема решена в MySQL
  5.7 от 5.7.23, когда
  caching_sha2_password клиентская поддержка
  был добавлен в клиентскую библиотеку MySQL и клиентские программы.)

• Подключитесь с помощью клиента MySQL 5.7 к учетной записи сервера до версии 5.7.
  который аутентифицируется с
  mysql_old_password . Это не удается для
  множественные причины. Во-первых, такое соединение требует
  --secure-auth=0 , который больше не является
  поддерживаемый вариант. Даже если бы он поддерживался, клиент 5.7
  не распознает плагин, потому что он был удален в
  MySQL 5.7.

• Подключиться с помощью клиента MySQL 5.7 из сообщества
  распространение на учетную запись сервера MySQL 5.7 Enterprise, которая
  аутентифицируется с использованием одного из LDAP только для предприятий
  плагины аутентификации. Это не удается, потому что Сообщество
  у клиента нет доступа к подключаемому модулю Enterprise.

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

Коннектор подключаемого модуля аутентификации — рекомендации по написанию

Различные реализации клиент-серверного протокола MySQL.
существует. Клиент C API libmysqlclient
библиотека — это одна реализация. Некоторые коннекторы MySQL (обычно
те, что не написаны на C), предоставляют собственную реализацию.
Однако не все реализации протокола работают с подключаемыми модулями.
аутентификация таким же образом. В этом разделе описывается
проблема аутентификации, которую разработчики протокола должны принять во внимание
учетная запись.

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

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

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

• В MySQL 5.7 libmysqlclient использует в качестве своего
  выбор по умолчанию либо
  mysql_native_password или плагин
  указан через MYSQL_DEFAULT_AUTH
  опция для mysql_options() .

• Когда клиент версии 5. 7 пытается подключиться к серверу версии 8.0,
  сервер указывает caching_sha2_password как
  его подключаемый модуль аутентификации по умолчанию, но клиент по-прежнему
  отправляет данные учетных данных либо
  mysql_native_password или как там
  указан через MYSQL_DEFAULT_AUTH .

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

Ограничения на подключаемую аутентификацию

В первой части этого раздела описаны общие ограничения на
применимость подключаемой структуры аутентификации
описано в Разделе 6. 2.17, «Подключаемая аутентификация».
во второй части описывается, как сторонние разработчики коннекторов могут
определить, в какой степени соединитель может использовать преимущества
подключаемые возможности аутентификации и какие шаги предпринять, чтобы
стать более сговорчивым.

Используемый здесь термин «собственная аутентификация» относится
для аутентификации по паролям, хранящимся в
mysql.user системная таблица. Это тоже самое
метод аутентификации, предоставляемый старыми серверами MySQL, до
реализована подключаемая аутентификация. «Родной
аутентификация» относится к аутентификации с использованием
учетные данные пользователя, который уже вошел в Windows, как
реализуется подключаемым модулем Windows Native Authentication
(«Подключаемый модуль Windows» для краткости).

• Общие ограничения аутентификации подключаемых модулей

• Проверка подлинности подключаемых модулей и сторонние соединители

Общие ограничения аутентификации подключаемых модулей

0

0
Connector/C++: клиенты , которые
использовать этот коннектор может подключиться к серверу только через
учетные записи, использующие встроенную аутентификацию.

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

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

• Connector/NET: клиенты , использующие
  Connector/NET может подключаться к серверу через учетные записи, которые используют
  собственная проверка подлинности или собственная проверка подлинности Windows.

• Connector/PHP: клиенты , которые
  использовать этот коннектор может подключиться к серверу только через
  учетные записи, использующие встроенную аутентификацию, при компиляции с использованием
  родной драйвер MySQL для PHP
  ( mysqlnd ).

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

• пользователей прокси: пользователя прокси
  поддержка доступна в той мере, в какой клиенты могут подключиться
  через учетные записи, аутентифицированные с помощью плагинов, реализующих
  возможность пользователя прокси (то есть плагины, которые могут возвращать
  имя пользователя, отличное от имени подключающегося пользователя). За
  например, подключаемые модули PAM и Windows поддерживают прокси-пользователей.
  mysql_native_password и
  sha256_password плагины аутентификации делают
  не поддерживает прокси-пользователей по умолчанию, но может быть настроен на
  Сделай так; видеть
  Поддержка сервера для сопоставления пользователей прокси.

• Репликация : Реплики могут
  не только использовать учетные записи пользователей репликации, используя собственные
  аутентификации, но также может подключаться через репликацию
  учетные записи пользователей, которые используют нестандартную аутентификацию, если
  доступен требуемый клиентский плагин. Если плагин
  встроенный в libmysqlclient , это
  доступно по умолчанию. В противном случае плагин должен быть
  установлен на стороне реплики в каталоге, указанном
  реплика plugin_dir system
  переменная.

• ФЕДЕРАТИВНЫЙ
  столы: A FEDERATED
  table может получить доступ к удаленной таблице только через учетные записи на
  удаленный сервер, использующий собственную аутентификацию.

Съемная аутентификация и сторонние разъемы

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

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

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

• Чтобы воспользоваться подключаемыми возможностями аутентификации,
  коннектор, основанный на libmysqlclient
  должны быть повторно связаны с текущей версией
  libmysqlclient . Это позволяет
  коннектор для поддержки подключений через учетные записи, которые
  теперь требуются клиентские плагины, встроенные в
  libmysqlclient (например, открытый текст
  подключаемый модуль, необходимый для аутентификации PAM, и подключаемый модуль Windows
  необходимо для собственной проверки подлинности Windows). Связь с
  текущий libmysqlclient также включает
  коннектор для доступа к подключаемым модулям на стороне клиента, установленным в
  каталог плагинов MySQL по умолчанию (обычно это каталог
  названный значением по умолчанию локального сервера
  plugin_dir система
  переменная).

  Если коннектор ссылается на libmysqlclient
  динамически, необходимо убедиться, что более новая версия
  libmysqlclient установлен на клиенте
  host и что коннектор загружает его во время выполнения.

• Другой способ для соединителя поддерживать заданный
  метод аутентификации заключается в реализации его непосредственно в
  клиент-серверный протокол. Connector/NET использует этот подход для предоставления
  поддержка встроенной аутентификации Windows.

• Должен ли соединитель иметь возможность загружать подключаемые модули на стороне клиента
  из каталога, отличного от плагина по умолчанию
  каталог, он должен реализовать некоторые средства для пользователей клиента, чтобы
  укажите директорию. Возможности для этого включают
  параметр командной строки или переменная среды, из которой
  соединитель может получить имя каталога. Стандартный MySQL
  клиентские программы, такие как mysql и
  mysqladmin реализовать
  --plugin-dir опция. Смотрите также
  Интерфейс подключаемого модуля клиента C API.

• Поддержка прокси-пользователя соединителем зависит, как описано
  ранее в этом разделе о том, является ли аутентификация
  методы, которые он поддерживает, разрешают пользователям прокси.

Класс аутентификации: управление учетными записями и аутентификация пользователей

Детали

{startverticalbanner}

 Аутентификация пользователя Класс PHP
==============================

Это простой класс аутентификации пользователя для PHP, который использует
база данных MySQL, доступ к которой осуществляется через MySQLi. 

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

Текущие функции следующие:

- login($username, $password): проверяет учетные данные пользователя
- register($username, $password, $verifypassword, $email): добавляет новую учетную запись пользователя в базу данных.
- newsession($username): создает новую сессию для пользователя
- deletesession($hash): удаляет существующий сеанс из базы данных и удаляет куки пользователя.
- sessioninfo($hash): извлекает информацию о сеансе из базы данных (UID, имя пользователя, дата истечения срока действия, IP)
- checksession($hash): проверяет, действителен ли сеанс
- randomkey($length): возвращает случайный ключ, используемый в качестве ключа активации, содержащий строчные/прописные буквы и цифры.
-activate($username, $key): активирует учетную запись на основе имени пользователя и ключа активации. 
- changepass($username, $currpass, $newpass, $verifynewpass) : изменяет пароль пользователя. Требуется текущий пароль
- changeemail($username, $email) : изменяет адрес электронной почты пользователя.
- resetpass($username, $email, $key, $newpass, $verifynewpass): отправляет электронное письмо с запросом на сброс и сбрасывает пароль пользователя.
- checkresetkey($username, $key): проверяет ключ сброса на основе имени пользователя, возвращает true/false
- deleteaccount($username, $password): удаляет учетную запись пользователя. Требуется текущий пароль
- addattempt($ip): регистрирует новую попытку аутентификации на основе IP-адреса пользователя.
- getattempt($ip): извлекает количество попыток из базы данных на основе IP-адреса пользователя.
- expireattempt(): удаляет журналы просроченных попыток из базы данных, должно выполняться как задание cron.
- LogActivity($username, $action, $additionalinfo): регистрирует использование пользователем класса с момента входа в систему до выхода из системы.  Включая попытки.
- hashpassword($password): хеширует пароль следующим образом: hash("SHA512", base64_encode(str_rot13(hash("SHA512", str_rot13($auth_conf['salt_1'] . $password . )))))

Расширенное шифрование приведет к практически невозможному взлому пароля. Сессия
система полагается на IP-адрес пользователя, и если он изменится, пользователю придется повторно аутентифицироваться.

Макет базы данных хранится в auth.sql, который вы можете легко импортировать с помощью PhpMyAdmin.

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

Имя: Класс авторизации Форум поддержки Базовое имя: класс авторизации Описание: Управление учетными записями и аутентификация пользователей Версия: 1. 0.0 Версия PHP: 5,0 Лицензия: Стандартная общественная лицензия GNU (GPL) Пользователи постоянно: 2120 пользователей Рейтинг за всё время: 1845 Недельные пользователи: 0 пользователей Недельный рейтинг: 180

Файл Роль Описание auth. cuonic.tk.png Экран Скриншот примера использования

Если вы знаете приложение этого пакета, отправьте сообщение автору, чтобы добавить сюда ссылку.

Файл	Роль	Описание
auth.class.php	Класс	Класс аутентификации PHP
auth.sql	Данные	Структура базы данных MySQL
config.php	Конф.	Файл конфигурации аутентификации
язык. Назад: Vba access recordset: Свойство Набор записей(Recordset) — Служба поддержки Майкрософт Вперед: Postgresql client windows: PostgreSQL: Windows installers