Коллеги, мой опыт работы с PHP огорчительно невелик, и сводится к написанию прикладных скриптов, для интеграции уже имеющегося зоопарка с платформами типа Asterisk. Поэтому я беспокою сообщество своим вопросом. Пожалуйста, подскажите простую, но надежную библиотеку для аутентификации пользователей. Никаких архитектурных излишеств, типа отправки писем или SMS не требуется. Нужен минимальный функционал, "по простоте напоминающий античность" - приходимец, попавший на одну из страниц, вводит логин и пароль. Если информация о нем находится в профильной таблице базы, приходимец оказывается на той-же странице и спокойно работает, больше к нему не пристают. Если нет - он оказывается на странице с Отрицательными Поздравлениями из которой узнает, что Здесь ему не Тут. (Разумеется, страниц может быть несколько и аутентификация должна быть единой: залогинился на одной - работай на всех.) Дополнительно очень хочется, чтобы почитавшие журнал "Хакер" пионэры не взламывали эту защиту всего за 5 минут времени, что увы, иногда бывает. ("И ещё как бывает!") Заранее признателен за рекомендации, Ogogon.
Ну если не брать встроенные в фреймворки механизмы, то достаточно просто PDO, никакой либы не надо. Если всё будет через подготовленные выражения, никакой либы особо не нужно --- Добавлено --- А, ну и для пароля использовать https://www.php.net/password_hash, https://www.php.net/manual/ru/function.password-verify.php для пароля
@mkramer, а авторизация? Сессии пыха? А защита от брута по логину/паролю и по ключу авторизации? --- Добавлено --- «Залогинился» – это аутентификация, а дальше авторизация. В принципе проще самому написать, чем ждать у моря погоды. Я бы дал, но у нас сейчас все крутится на своих серверах, так что сами понимаете. --- Добавлено --- А что говорит Packagist и т.п.?
А регистрация будет? Ведь ему как то нужно сначала создать учетку на сайте. Так, поищи готовое, легко по слову - Authentication - на Packagist , видно что если покрутить, вроде приличное выдает. Так то по сути это две формы - регистрация и вход. И функционал автовхода по кукам
Благодарю. Я хочу написать совсем крошечный специализированный фреймворк в жанре web-консоли, и мне нужен доступ с аутентификацией. Даже авторизация, в полном смысле, пока не требуется: любой, кто зашел - заведомо админ. И меня больше беспокоит обратная сторона медали - безопасное взаимодействие с приходимцем. Я почитал всякие ужасы про кражу сессий и их параметров, после чего понял, что нюансов там весьма много и многие из них весьма значимы. Взаимодействие с базой меня беспокоит гораздо меньше - тут я чувствую себя увереннее, и если нужно, я на первое время, пользователей прямо из её консоли создам. Поэтому, я хочу понять, как правильно построить получение аутентификационной информации и контроль целостности сессии, чтобы это было достаточно надежно. Ogogon.
Ну сейчас не так просто украсть сессию, как во времена, когда её айди прямо в гет-параметрах торчал, сейчас это http-only кука, но те, кому это важно, делают проверки. Можно сделать, например, привязку к региону IP, можно даже к самому IP, хотя это не всем удобно будет (не все на белых айпи сидят). Можно привязаться к юзер-агенту. Это всё просто делается - сохраняешь в сессию выбранный параметр, и проверяешь при каждом запросе, с того ли самого айпи/региона/браузера тебя беспокоят. Но тут такое, а реально кому-то захочется красть сессии с твоего сайта?
Не хочу произносить "всё зависит от", но придется. Если тебе надо PHP_BASIC авторизацию - это когда выводится прямо в браузере стандартная всплывашка для пароля - проще всего обойтись одним IF для проверки (загуглить как) Если тебе надо с личным кабинетом и блекджеком - тогда всё сложнее. В ларавель фреймворке например есть laravel/passport и второй пакет (не помню я ихних названий, они любят придумывать всякие массонские и рептилоидские), тот второй поддерживает OAuth (вход через ваш сервис на другой сервис подобно тому как ты заходишь через гугл) из коробки, но юзать их - придется перечитать нормальный талмуд и "привыкнуть". Важный момент, что "вход через гугл" все равно пишется с нуля, то есть их поддержка OAuth это именно возможность сделать "вход через вас", а не "вход к вам" Если опыта достаточно - можно попробовать воткнуть в фоне wordpress (админка сразу в подарок получится), но там других проблем выше крыши, в том числе с тем, что вордпресс очень хочет быть основной штукой на сайте и чтобы сделать его не таким требовательным, там танцев с бубном нормально. Я обычно на всех проектах пишу авторизацию с нуля. По сути авторизация это маршруты: 1) POST /login - передаешь login (опционально телефон-почту или все вместе, сильно усложняется если несколько) и возможно пароль (нынче тренд делать авторизацию без пароля вообще, так называемый "демо-режим", а после входа через телефон-почту - пускать по-нормальному). Выставляет куку или выдает токен в ответ. 2) GET /me - вернет текущего юзера, иногда удобна фронтенду, чтобы получить уровень доступа юзера (когда ты его реализуешь) 3) GET /logout - очищает тебе куки, сессию, или деактивирует права токена 4) POST /register - создает нового юзера (тренд - соединять вместе с логином, но число запросов в БД и проверок на уникальность тогда растет) 5) Еще в коде придется сделать метод типа ->authenticate() который запускается на некоторых или всех страницах, и считывает куку/токен, чтобы понять а кто ты вообще. Это не путать с /login, первый это когда ты данные передал, а второй это когда ничего не передавал, а кука пришла сама. 6) Если играться с токенами, то некоторые делают еще роут POST /refresh-token, который блочит старый токен и выдает новый. Токены это типа вместо куки со случайной строкой туда-сюда летает условный js-обьект (ассоциативный массив) зашифрованный подписью, где можно еще свои поля добавить, а заодно не хранить в БД всех, кто вошел (токен подписан, а значит неизменен, если проверка подписи удалась - значит токен получен на твоем сайте, а стало быть - настоящий), но тут же трабла - выдаешь токен и даже если ты человека забанишь - токен то остался, будет ходить дальше. Придется после распознавания токена принудительно делать проверку роли. Поверху к этому обычно требуется какая-то система проверки доступов. Опять же из готовых злющие дредноуты. Ты можешь убить месяц пока научишься писать свою авторизацию. Хочется стартануть - поставь прям целиком ларавель и вкури их доку, если ничего не трогать - работать будет, это быстрее чем разбирать что зачем нужно в авторизации, где там криптография, причем тут JWT и чем RBAC/ABAC отличаются, как сделать в 2024 отсылку почты, учитывая что гугл сопротивляется, и какой SMS сервис выбрать для телефонов, почему Wildberries юзает звонки и последние 4 цифры, чтобы экономить на SMSках и тд.