bazileсохранай информацию о факте успешной аутентификации в cookie.Очень плохой совет. Кука легко читается/правится. Со всеми вытекающими.


bazileЧто касается сессии она и должна быть короткоживущей чтобы не тратить зря ресурсы сервера.Не понятно, как время жизни сессии соотносится с ресурсами сервера. Или имеется в виду файл сессии? Ну так он небольшой обычно, что при нынешних гигабайтах дискового пространства не то что не фатально, но даже и не очень то напряжно. Нужна сессия на конкретной странице - стартуете, не нужна - не стартуете. А так сессия хоть год может жить не прося каши...


Алексей Смирновв cookie будет достаточно прописать $_SESSION['blnIsLogin'] = True; (при достаточной сноровке) и всё, доступ в базу обеспечен даже без пароля.Ничего себе... А примерчик такой "сноровки" есть?


Алексей СмирновЗаметил, что на следующий день на сайт приходится заново выполнять вход. Один день для хранения сессии слишком мало, т.к. пишу сайт для внутренней корпоративной локальной сети и сбрасывать авторизацию так часто нет никакой необходимости.
В чем может быть причина?Сложно сказать, слишком мало информации.
Вообще, принцип примерно такой. Хранить сессию в базе, отдельным полем хранить время последнего старта сессии (или время окончания жизни сессии). Время жизни куки, идентифицирующей сессию, установить достаточно большим (дня два, например). В функциях поддержки при старте сессии проверять время и принимать решение о продолжении существующей или о закрытии устаревшей и старте новой сессии.

bazilevkleКука легко читается/правится. Со всеми вытекающими.
Легко читается - да. Легко правится - не обязательно.Кто или что может мне помешать отправить куку произвольного содержания на сервер? Мой HTTP-клиент - что хочу - то и отправляю. Могу отправить и "пользователь авторизован", если, как предлагается выше, хранить этот признак в куке. Не? ;-)

bazileПопробуй например подобрать куки для sql.ru. Он использует af_remember, af_data и af_ext_opts для этого. Если это так легко, то тебе не составит труда написать сообщение от чужого имени.Даже и не буду пытаться пробовать В том и фишка, что кука не должна хранить каких-то потенциально опасных или сравнительно легко подбираемых данных, таких какbazileинформацию о факте успешной аутентификации

Алексей СмирновЭто может быть я сам неправильно авторизацию сделал. Я храню признак того, что пользователь залогинился именно в переменной сессии $_SESSION['blnIsLogin'].Что храните факт авторизации в переменной сессии, а не на клиенте - это Вы правильно делаете.


Алексей СмирновА про жизнь сессии 1 день, я неправильно написал. Сегодня вообще понял, что сессия у меня живет до закрытия браузера. При следующем открытии снова спрашивает пароль к сайту.Давайте смотреть как работает механизм сессии. Это понимание потребуется как раз для "ручной" реализации.
Когда стартует сессия, то на клиенте устанавливается кука с идентификатором сессии, а на сервере создаётся файл (или запись в базе данных), который (или которая) однозначно определяются как раз этим идентификатором. Важно заметить, что PHP умеет самостоятельно определять полученный из куки идентификатор и стартовать для пользователя именно его сессию. Второй момент - PHP имеет параметр, определяющий время жизни сессии. По дефолту это параметр session.gc_maxlifetime, имеющий значение 1440 секунд. Это означает, что при неактивности пользователя (сессия не использовалась) по прошествии указанного времени на стороне сервера сессия будет удалена. Если вебсервер создаётся специально для одного единственного приложения и его настройки Вам подконтрольны, тогда вполне можно подкрутить этот параметр, но если уж всё вручную, то ну нафик...

Теперь смотрим на сторону клиента. Кука имеет некоторое, вполне определённое время жизни или "до закрытия браузера" (например, смотрите в доке параметр expire). По прошествии оного времени кука просто перестаёт существовать и при следующем обращении на сервер идентификатор попросту не отсылается и, даже если старая (существующая) сессия ещё не "померла" на сервере, она не может стартовать.

Вот два случая, когда данные сессии теряются - по инициативе сервера или по инициативе клиента. Есть еще убиение сессии по инициативе программиста, но его рассматривать не будем. :-)

Далее, касаемо восхода Солнца поддержки сессии вручную. Вы реализуете хранение сессии в БД. Хорошо. В таблице сессий должны быть минимум три поля - идентификатор сессии (чтобы определить, за каким пользователем закреплена данная сессия), данные (там будет содержаться серилизованный массив), время последней активности пользователя.

Как разруливать. Примерно таким образом... Когда поступает задача на старт сессии, смотрите в куках наличие идентификатора сессии. Далее варианты...
- идентификатора нет (новая сессия) - генерите идентификатор, устанавливаете этот идентификатор в куку с достаточно большим временем жизни, делаете запись в БД с этим идентификатором и отметкой времени активности.
- в куке идентификатор есть - тут опять возможны варианты
-- проверяете наличие этого идентификатора в БД - опять варианты
--- в БД идентификатора нет - старт новой сессии (можно с переустановкой куки)
--- в БД идентификатор есть - проверяете актуальность сессии... варианты
---- сессия актуальна - обновляете соответствующую запись, установив новую отметку времени активности, читаете из БД данные и восстанавливаете массив...
---- сессия просрочена - старт новой сессии, см. выше

Проверять или нет актуальность сессии, обновлять ли метку времени - это по усмотрению. Можно не проверять и не обновлять, если не хотите управлять временем жизни сессии на стороне сервера.

Уффф... много получилось, да вроде бы, не слишком запутанно

Алексей СмирновОказывается в куках надо хранить некий хэш, хранить тот же хэш в БД и при заходе пользователя на сайт сравнивать их.Ну да, об этом и писал. Можно и хеш - так часто делают. А в принципе, не имеет значения, каким образом получен идентификатор. В любом случае, он должен быть уникальным для каждого пользователя и не должен подбираться тупым перебором сполпинка.

Алексей Смирнов, не понимаю, как одно с другим связано.

Алексей СмирновПри использовании протокола HTTP (без SSL) высока вероятность перехвата этого ХЭША. Достаточно будет на компьютере злоумышленника в файле cookies.txt браузера (или cookies.sqllite для Мозиллы) записать в переменную этот ХЭШ и доступ в систему обеспечен.

Чтобы обезопасить канал связи рекомендуют для больших проектов использовать SSL ( https://). А у меня большой корпоративный проект.Всё верно говорите. Для "большого корпоративного" стоимость сертификата вряд ли окажется непреподъёмной. Да, как вариант, можно использовать спмоподписной сертификат или бесплатный...

Варианты без SSL уже рассматривали? Например, можете попытаться добавить дополнительно признак привязки сессий к IP-адресу компьютера.

Алексей СмирновИ нашёл материал по созданию самописного сертификата, но проще 200р. заплатить, чем ещё разбираться с этим.Разбираться там буквально на четыре команды, которые можно копипастить из "шпаргалок". Но главная проблема не в этом. Самоподписной сертификат пользователям придётся акцептировать самостоятельно (браузер задаст вопрос о доверии к сертификату). В этом смысле проще заплатить немного денег, чем напрягать пользователей лишним запросом.