Пару вопросов от новичка: 1. Как быть, если IP динамический? При каждом новом подключении к инету заново логин с паролем вводить? 2. UserAgent - имеется ввиду id пользователя?
1. да, придется. но не такая уж это проблема. разве что ты используешь какое-то специальное ПО, которое ежеминутно меняет твой IP. 2. это специальный заголовок "про браузер". если ты одновременно откроешь IE и Chrome, IP у них будет одинаковый, а UA разный. p.s. вообще паранойа по поводу безопасности и удобство пользователя всегда будут конфликтовать.
Тут мы натыкаемся на тот факт, что аутентифицированность пользователя и сессия - не одно и то же. Смена IP между сессиями это совсем другое. И решается постановкой галочки "запомнить меня". Как ты обеспечишь ее защищенность и принцип работы - дело третье. Многие сервисы, например, пробивают внутри UserAgent при этом тип устройства, ось, а IP пробивают по геобазе. Мол, если между сессиями ты оказался в другом городе или другой стране - тебя, скорее всего, попросят заново ввести пароль. У меня же в описании механизма защиты сессии речь шла именно про ситуацию, когда сессионная кука утекла от пользователя в тот момент, когда он на сайте. Чтобы злопыхатель параллельно с пользователем не зашел и, например, пароль ему не сменил. Или еще чего похуже. При нарушении идентичности отпечатков и пользователь и злоумышленник получат разлогин с извиняшками. Пользователь при этом просто ругнется и снова введет пароль, попутно сгенерировав новый отпечаток. Злоумешленник же останется ни с чем. Главное уяснить тот факт, что сессия и автологин - это разные вещи. При включенном автологине, когда ты ушел с сайта, сессия уже будет уничтожена, вместе с твоими фингерпринтами и на то, какой у тебя будет IP при следующем заходе - системе уже плевать.
И вообще сессия не является чем-то необходимым для узнавания пользователя, это всего лишь вариант реализации. ПМСМ, лучше если не завязываться на сессию. Меньше зависимостей, в т.ч. ментальных Вот как начать пользоваться state-less (session-less) аутентификацией, если мозг твой приучен к сессии?
Вы для меня монстры программирования... интересно, бывают существа , которые больше знают php чем вы?
педик, ты свои не здоровые фантазии при себе держи В реальном мире а за такие высказывания бью в морду
Вы под защитой сессии подразумеваете что-то в этом роде? PHP: //При удачной аутентификации при входе. $_SESSION['ua'] = $_SERVER['HTTP_USER_AGENT']; $_SESSION['ip'] = $_SERVER['REMOTE_ADDR']; $_SESSION['time'] = $_SERVER['REQUEST_TIME'] + 100; PHP: //Проверка текущей сессии на каждой странице. if ($_SERVER['HTTP_USER_AGENT'] == $_SESSION['ua'] AND $_SERVER['REMOTE_ADDR'] == $_SESSION['ip'] AND $_SERVER['REQUEST_TIME'] < $_SESSION['time']) { $_SESSION['time'] = $_SERVER['REQUEST_TIME'] + 100; //Авторизированная информация. } else { session_destroy(); }
Реквест тайм не нужен, и в остальном все несколько проще храни не сами данные, а просто склей их в одну строку и возьми хэш. Его и проверяй потом.
По примеру как предлагал romach в сообщении #103? PHP: $_SESSION['user_hash']=md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR']); А как тогда правильно реализовать "запомнить меня"?
Сессия это файл на диске и его имя в cookie у пользователя, файл с диска могут удалить, это на севере, ещё настройки сессии в PHP могут укоротить жизнь сессии, по хорошему, если пользователь не выбрал чтобы его запомнили, как закрыл страницу/браузер сессия должна помереть, а точнее её идентификатор в cookie, если нужно запомнить, то можно хранить сессию в базе и удалять можно раз в пол года от мусора, главное настроить сессии чтобы они долго жили или обновлялись у пользователя в браузере, тот самый cookie с идентификатором
Не советую искусственно увеличивать срок жизни сессии! Надо решать задачу другими способами. Во-первых, это может не работать ))) Например в Дебиан Линукс сборка сессионного мусора идёт не по стандарту. пруф. Во-вторых, если заработает, ещё хуже: сессионные файлы создаются даже тогда, когда странички читает бот, не поддерживающий куки и значит сессии тоже — тогда PHP будет создавать новый сессионный файл на каждой страничке где обращение к session_start(). То есть ну очень много файлов. И если файлы долго не чистить, их будет ппц как много, могут начаться проблемы в файловой системе.
@artoodetoo что-то по пруфу не понял в чем проблема. Ну держит он каталог сессии 1733 для root:root. Все любые пользователи-владельцы апачей, фпм-ов и прочих пхп-машин - могут спокойно писать туда файлы со своими сессиями. Более того, они же и становятся владельцами этих файлов, значит и читать их смогут, и писать. И заглянуть к соседу в рамках одного пользователя-владельца, если знают его сессид. Не смогут получить листинг каталога - и отлично. Пхп-машина ищет сессию по той строке, что в запросе пришла. Файл либо будет, либо не будет. Флага исполнения (+x, единичка) вполне достаточно для этой операции. Ну а рут под своей семеркой может спокойно прочитать листинг каталога, отобрать старые файлы и похерить их. Всё очень даже логично оформлено. В чем проблема-то?
Хорошее уточнение, я вскользь упоминал, что сессии можно хранить в базе, тогда там можно и время её удаление удобно хранить, если это бот, то пусть мрёт через час, если человек захотел запомнить, то пусть живёт по дольше.
Я присоединяюсь к совету - не реализовывать запоминалку через долгие сессии. Сессия это сессия. Она нужна чтобы между страничками ходить. Запоминалка - это уже механизм идентификации между сессиями.
я не стартую сессию, пока в заголовках нет нужной плюшки, либо пока пользователь не выполнит какое-то действие, где однозначно применяется механизм сессий. анонимные корзины хранятся там же где и основные, но их идентификаторы связаны с плюшками, которые выдаются анонимам. как только посетитель далеко ушел - корзина уничтожается. зарегистрированный же пользователь всегда имеет одну корзину и она живет столько, сколько живёт его аккаунт. очень удобно для откладывания покупок.
@Ganzal В том, что процессом удаления пхп-шных сессионных файлов сам пхп уже не занимается. Это внешний механизм со своими собственными настройками. Решения по поводу срока жизни непереносимы между дебиан и другими системами.
@artoodetoo Что опять же не вызываем у меня ассоциации с проблемой. Дебиановский удалятор сессий это обычный башскрипт, который читает все доступные конфигурации, выхватывает из них место хранения и длительность сессий, и потом тупо ищет и удаляет все устаревшие файлы в каждом хранилище. Да, он не зацепит какой-то конфиг, если этот конфиг будет прятаться где-то еще. Но так ли часто частные конфигурации вносят какие-то уж очень заметные изменения в механизм сессий? Даже если оставить уборку мусора пхп-машине, то это все равно нужно будет делать какой-то отдельный демон, который будет знать про все возможные конфигурации и учитывать их пожелания. Например, кто-то на своем сайте зарубил дневные сессии, но оставил их храниться в стандартном каталоге. Что делать уборщику мусора со встреченным файлом? К какой конфигурации его относить - к той что 1440 секунд или к той что 86400? Значит надо помимо самого сессионного файла еще и хранить про него какую-то метаинформацию. Нужна ли такая дополнительная нагрузка в простом механизме? Кажется многие решили что не очень-то и нужна.
@Ganzal я не пытаюсь сказать, что дебиан делает что-то плохо. я говорю о том, что задокументрированные и вроде бы проверенные пхп-шные настройки могут не иметь эффекта. Например session.gc_maxlifetime на Дебиане.