- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Как правильно реализовать авторизацию на сайте, при условии что браузер должен запоминать юзера.
Есть вариант такой:
Отправляем логин и пароль, пароль хэшируем функцией password_hash().
При авторизации сравниваются строки хэша.
В случае успеха при авторизации записываются куки ID и хэш пароля, при каждом обновлении страницы эти данные сравниваются.
Это самый простой способ который только можно придумать. Хочется что-то более усложненное, например так чтобы меньше оставлять "палева" в куках или так чтобы при каждом обновлении страницы не сверялось совпадении пароля и ID по куке, а например можно рассмотреть вариант если сессия с ключом для этого юзера запущена - то не делать запросы к бд для сравнивания id и пароля. Посоветуйте что нибудь пожалуйста!
Почитайте как работать с сессиями и как через них делается авторизация.
Не нужно велосипед придумывать, уже всё сделано до вас.
Сессия, грубо говоря, это та же аутентификационная кука.
Сложнее вы вряд ли что-то придумаете.
Пользователя можно определить или по логину-паролю, или по какому-то секретному идентификатору (куке).
Сложнее можно сделать только с https и аутентификацией с проверкой сертификатов, выдаваемых индивидуально каждому пользователю :)
Безопасно ли хранить хэш пароля и id в куках? я думаю нет. Для выхода из такой ситуации можно прилепить опционально привязку к ip, но это не очень удобный вариант... Что можно придумать?
В куке нужно хранить не хэш пароля, а зашифрованный идентификатор, который на сервере можно расшифровать.
Ну и туда же добавить другие необходимые данные, при необходимости, например, срок действия, ip-адрес и пр.
;12794042]а зашифрованный идентификатор, который на сервере можно расшифровать
Что в нем должно шифроваться?
Почитайте как работать с сессиями и как через них делается авторизация.
Не нужно велосипед придумывать, уже всё сделано до вас.
Не совсем же, первый раз запустить для юзера сессию тоже надо ☝
Что в нем должно шифроваться?
Написал же, идентификатор пользователя… ID…
Или у вас только логины/пароли? Ну можно логин вместо ID
;12794077]Написал же, идентификатор пользователя… ID…
Или у вас только логины/пароли? Ну можно логин вместо ID
Так а суть в чем? если куки всегда могут подменить, я имею ввиду то что как-то надо строку менять по времени и последние изменения в базе хранить... Объясните подробнее или киньте линк на статью, я не до конца понимаю
если куки всегда могут подменить
Можно поподробнее, как это сделать? :)
Если куки могут подменить, то и пароль могут украсть.
И если так рассуждать, то даже если авторизация с каким-нибудь usb-донглом, то на компьютере может быть троян, который выполнит нужные действия от имени пользователя.
;12794122]Если куки могут подменить, то и пароль могут украсть
:) Я понял. Думал что стоит заморачиваться с интервальной сменой хэша в куке)