Меню
Что нового?

Авторизация, варианты реализации

sanu0074

sanu0074

Новичок
Как правильно реализовать авторизацию на сайте, при условии что браузер должен запоминать юзера.
Есть вариант такой:

Отправляем логин и пароль, пароль хэшируем функцией password_hash().
При авторизации сравниваются строки хэша.

В случае успеха при авторизации записываются куки ID и хэш пароля, при каждом обновлении страницы эти данные сравниваются.

Это самый простой способ который только можно придумать. Хочется что-то более усложненное, например так чтобы меньше оставлять "палева" в куках или так чтобы при каждом обновлении страницы не сверялось совпадении пароля и ID по куке, а например можно рассмотреть вариант если сессия с ключом для этого юзера запущена - то не делать запросы к бд для сравнивания id и пароля. Посоветуйте что нибудь пожалуйста!
 
Посмотри как реализовано в фремворках. Например в Symfony2, Yii, Kohana, laravel
 
Про laravel хорошая шутка, недавно эпик баг выловили вот этот баг с запоминанием пароля, можно смотреть как фиксили в последней версии.
 
Для начала нужно просто посмотреть ТЗ, там должно быть указано. Если пишешь для себя то перед тем как писать составь ТЗ, где подробно опиши "зачем нужна авторизация" и "какие вопросы она решает". В зависимости от цели реализаций можно миллиард придумать, и каждая в своём случае будет правильной. Универсального ответа нет.
 
Ставь в куку обычный хэш "логин-пароль-соль", а если у тебя всё жутко секретно, то записывай в базу дату последнего коннекта, и через полчаса бездействия не пускай без ввода логин-пароля.
 
riff, а зачем это так делать?
У нас же сессия - тоже моделька, почему бы в ней не хранить время первого логина?
 
riff, от того, что сессию не используешь как хранилище - она не перестает быть сессией. На мой взгляд.
Ставь в куку обычный хэш "логин-пароль-соль"
Нажмите для раскрытия...
Это и есть сессия
 
  • Like
Реакции: WMix
WMix, не обязательно. Как минимум можно сделать куку ограниченной по времени. Но доверять куке не стоит - так что, в сессии пишем время, когда ее нужно прибить и каждый запрос проверяем.
 
каким образом на значение hash повлияет ограничение по времени если оно равно
хэш( "логин-пароль-соль" ),
подождем пока пользователь перелогинится, и опять все работает?
 
ну вот если бы да кабы. но и в timestamp есть уязвимость, это число всегда больше чем известное, причем на сколько, тоже заранее известно, где-то эта инфа передается, иначе не знаю как ты угадаешь, что это тот пользователь, кем он себя именует. но угадать значительней сложнее, согласен, главное, что мы это понимаем :)
 
WMix, вместо timestamp может быть любая динамическая информация... uniqid, например:)
Но свою ошибку я понял, нельзя не добавлять что-то динамическое в значение куки
 
Хорошо реализована система авторизации и авто-авторизации (при установленной галочке "Запомнить меня") в форуме на открытом коде FluxBB. Например.
Кука флакса при авторизации (аутентификации) пользователя проверяется в файле login.php и при успешной авторизации переустанавливается в браузере пользователя.
Кука флакса при авто-авторизации проверяется через файлы index.php, включающем common.php, включающем functions.php (строка 42 в common.php) вызовом функцией check_cookie() (строка 154 в common.php), и при успешной авто-авторизации переустанавливается функцией pun_setcookie() (в файле functions.php).
 
doran7, какая вообще ценность твоего сообщения? Зачем расписывать какую-то авторизацию в вакууме? Строки могут поменяться, имена методов тоже.
 
doran7 написал(а):
Хорошо реализована система авторизации и авто-авторизации (при установленной галочке "Запомнить меня") в форуме на открытом коде FluxBB. Например
Нажмите для раскрытия...
Такой код не должен быть опенсорсным. При его чтении ощущаешь себя как-то так:
post-3-13453800341238.jpg
 
Кука со временем жизни
hash( пароль . секрет . время ) . время
На сервере проверяем время и считаем хеш как защита от подмены

hell0w0rd написал(а):
riff, от того, что сессию не используешь как хранилище - она не перестает быть сессией. На мой взгляд.
Это и есть сессия
Нажмите для раскрытия...
Все же в 99% когда человек на форуме php говорит "сессия" - он имеет ввиду механизм php. Во избежании путаницы лучше не путаться.
sanu0074 написал(а):
Это самый простой способ который только можно придумать. Хочется что-то более усложненное, например так чтобы меньше оставлять "палева" в куках или так чтобы при каждом обновлении страницы не сверялось совпадении пароля и ID по куке, а например можно рассмотреть вариант если сессия с ключом для этого юзера запущена - то не делать запросы к бд для сравнивания id и пароля. Посоветуйте что нибудь пожалуйста!
Нажмите для раскрытия...
В БД все-равно рекомендуется глянуть на предмет - не удален ли этот пользователь уже. Да и вообще использование механизма сессии как механизма кеширования ("что бы в базу не лазить") не совсем верно. Если не нравится "палево", просто генерируете уникальную строку, ставьте ее в куку и пишите в базу соответствие "строка - user_id".
 
Войдите или зарегистрируйтесь для ответа.
Сверху