Клиент не хранит в сессиях данные, в сессиях хранятся данные установленные сервером и эти данные имеют исключительный уровень доверия. Local Storage это данные, к которым нет никакого доверия.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Зачем нужны сессии на сервере и клиенте если есть базовая авторизация и localStorage
- Автор темы студент№25
- Дата начала
- Статус
В общем , есть Session Storage (временные) и Local Storage (постоянные), оба в JavaScript. Это клиентские хранилища. Есть сессии в PHP - это серверные хранилище, которое ни как не связано ни с Session Storage, ни с Local Storage. Читайте: http://phpfaq.ru/sessions и разбирайтесь.
Как только попробуете написать авторизацию и напишите ее, покажите нам код.
Повторюсь - без этого опыта с ваше стороны дальнейшая дискуссия не будет иметь никаких результатов.
Как только попробуете написать авторизацию и напишите ее, покажите нам код.
Повторюсь - без этого опыта с ваше стороны дальнейшая дискуссия не будет иметь никаких результатов.
студент№25
Новичок
- поясни что это такое и зачем
чего тебе для доверия не хватает если есть доступ к БД или файлам, и если браузер постоянно шлет логин и пароль авторизации
1. Браузер не должен постоянно слать логин авторизации и пароль.
2. Попробуйте организовать пошаговый интерфейс с валидацией данных на стороне сервера.
Вурдалак
Продвинутый новичок
Сессии безотносительно к реализации и месту хранения — это временные данные. Временные данные — это «устаревший рудимент для тупорылых людей»? Ты правда вечно хранишь данные для многоэтапной авторизации? Молодец.
scorpion-ds
Новичок
студент№25,зачем постоянно слать логин и пароль, если "ключ" с информацией об авторизации можно хранить в сессии? К примеру, что бы каждый раз отправлять логин/пароль их придется хранить где-то локально, что уже небезопасно.
студент№25
Новичок
поясняю подробнее:
1) сервер запрашивает базовую авторизацию
2) далее введенные данные автоматически передаются от браузера к серверу на любых страницах где требуется идентификация клиента
- тоесть ввел один раз и потом автоматом
сервер всегда видит кто к нему обратился
Откуда?
Чел собирается в JS слать хидден поля логина и пароля
)) Значения брать из JS Storage.MiksIr
miksir@home:~$
Все верно, если у вас базовая авторизация, никакая сессия не нужна.
scorpion-ds
Новичок
Раз это судя по всему один человек и речь как выяснилось идет об "базовой авторизации", то это недопустимо из-за отсутствия возможности стилизации, собственно там об этом автору сказали.
студент№25
Новичок
- ты не понял меня. читай занова ))Чел собирается в JS слать хидден поля логина и пароля
студент№25
Новичок
-вот!
я об этом же
при использовании базовой аутентификации браузер автоматом шлет логин и пароль всегда после первого введения до конца сеанса
студент№25
Новичок
- ответы типа "а потому что это нельзя разукрасить" мне нафик не нужны пардоньте
я дядька серьезный, мне всяческое балавство не надо
аутентификация это системная функция, и она может быть любой сложности вплоть до скана роговицы
MiksIr
miksir@home:~$
У базовой аутентификации есть минусы
- сложно управлять "временем сессии" на стороне сервера и делать всякие кнопки типа "логаут"
- в современном мире пароли хранят в виде специальных хешей с повышенным временем расчета (как защита от перебора). А базовая аутентификация в своем базовом варианте подразумевает проверку пароля на каждый запрос.
- раскрашивание - тоже весьма серьезная причина сама по себе - удобство использования, вывод ошибок и т.п.)
Да и вообще то, что у вас пароль передается каждый запрос - не способствует повышению безопасности.
- сложно управлять "временем сессии" на стороне сервера и делать всякие кнопки типа "логаут"
- в современном мире пароли хранят в виде специальных хешей с повышенным временем расчета (как защита от перебора). А базовая аутентификация в своем базовом варианте подразумевает проверку пароля на каждый запрос.
- раскрашивание - тоже весьма серьезная причина сама по себе - удобство использования, вывод ошибок и т.п.)
Да и вообще то, что у вас пароль передается каждый запрос - не способствует повышению безопасности.
студент№25
Новичок
-не убедил
аутентификация может быть любая - например дайджест, там вроде шифруется логин и пароль
время сессии и логаут - проблемы решаемые, дело привычки
На самом деле этих неудобств набирается вагон и маленькая тележка
И все они сводятся к невозможности управлять авторизацией с сервера.
И в совокупности приводят к отказу от использования базовой авторизации.
Для теоретика, который ни одной авторизации в своей жизни не реализовал, это, несомненно, "проблемы решаемые".
Для реального использования подходят только сессии.
Дайджест, кстати, давно на свалке истории. Важностьхэширования пароля на сервере в разы перевешивает важность хэширования его при авторизации.
И все они сводятся к невозможности управлять авторизацией с сервера.
И в совокупности приводят к отказу от использования базовой авторизации.
Для теоретика, который ни одной авторизации в своей жизни не реализовал, это, несомненно, "проблемы решаемые".
Для реального использования подходят только сессии.
Дайджест, кстати, давно на свалке истории. Важностьхэширования пароля на сервере в разы перевешивает важность хэширования его при авторизации.
MiksIr
miksir@home:~$
Digest - это во-первых не базовая (а digest), а во-вторых, там проблемы с хранением пароля на сервере. Даже если использовать промежуточный хеш для хранения на сервере - он обычный md5, что не стойко к подбору.
> время сессии и логаут - проблемы решаемые, дело привычки
Вопрос не привычки, а использование стремно-выглядящих решений для реализации
> время сессии и логаут - проблемы решаемые, дело привычки
Вопрос не привычки, а использование стремно-выглядящих решений для реализации
- Статус