@Евгений мне однажды удаляли меньше чем за сутки. Правда, это было на обычном имгуре, не на SO

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

С точки безопасности, как я понимаю, злоумышленик, для авторизации, должен знать этот уникальный индетификатор. Тогда как я понимаю, чтобы усложнить задачу, злоумышленику, нужно сделать больше привязок, типа генерация индентификатора к примеру в в связке с user-agent (это как пример) можно еще айпи, но тогда если динам, то будет всегда дисконектить. Я все верно понимаю ?

А что по поводу сессий PHPSESSID пока что не дошел, так как еще возник вопрос, о том, как они будут удаляться если пользователь, вместо Logout закрыл вкладку. То сессия останеться на сервере.

То есть, пока решают технических задачи и логику работы самой системы. Дальше, проще конечно, аяксы прикрутить и т д. Цель, создать современную панель авторизации

@webstackoverload Видимо, не всё ясно с сессиями. Сессия хранится на сервере, ей всё равно, что кто-то закрывает вкладку. Но у сессии есть что? Время жизни.

@webstackoverload Ну что значит "какой-то уникальный идентификатор со сроком годности"? Используйте для этого идентификатор сессии на сервере.

@webstackoverload В чём её современность?

@AK Как это все равно ? К примеру если человек нажал на Logout в функции которой прописано убить сессию, то ее на сервере не больше не будет. То есть я хочу понять логику работы авторизации так, чтобы не мусорить и при этом было все просто и безопасно.

@webstackoverload А если не нажал? :)

Окей, я же явно написал: вы не до конца понимаете. Вы хорошо понимаете, что будет если нажал logout. А если не нажал - не понимаете. Вот вам и объяснено.

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

@AK Просто пока что на лету пишу, разбираюсь, так что возможность того что я что-то не понимаю пока что велика. Но главное это понять логику так, чтобы это было просто и безопасно.

@webstackoverload Докажите, что работает нехорошо. Покажите статью, укажите для какой версии PHP это было актуально, в каком году.

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

Я слышал подобное было характерно для PHP старых версий, для серверов под большой нагрузкой. В них предлагалось типа хранить сессию в SQL сервере. Ну, гм, если это ваш вариант и у вас выделенный SQL...

(В холивары какая нагрузка считается большой не вступаю. Если вы сами не знаете -- вероятно у вас никакой не хайлоад и вы велосипедите слишком рано)

Но если вы не пощупали стандартный движок сессий -- то у меня агроменный скептицизм, что пытаться сделать лучше получится с первой попытки, а тогда встаёт вопрос "а нафига?"

@AK Я Вас понял, тогда поэксперементирую с временем жизни сессии и потом посмотрю как работает мусорщик, в общем протестирую скаже так его работу.А сейчас логика такая: При заходе пользователя на сайт, пытаемся из установленных ранее (если уже авторизировался) кукисов получить hashid и если она есть, делается select запрос в базу, которые вытаскивает данные пользователя и помещает их в сессию (то есть генерируеся сессия е нужными для работы данными). Если кукисов с hashid нет

@AK тогда отправляем пользователя на страницу авторизации, также если кукисы будут иметь, чужеродные символы, они будут убиваться и опять будет происходить перенаправления на авторизацию.

Зачем класть в куки hashid, если можно положить id сессии?

@AK думаю можно, ибо когда читал типа теорию, там писали об уникальном айди, может где-то что-то пропустил, написал функцию, типа генерации уникального хеша..

@AK Но ладно, как сама логика ? Просто хочу именно логически правильно выстроить, когда это будет работать хорошо и протестированно, уже потом добавлять плюшки типа аякса и т д В плане "нано" технологий : )

@webstackoverload Такую логику писал ещё 10 лет назад, поэтому я прямо говоря не вижу в ней ничего "современного".

@AK Может и писали я никогда не писал формы авторизации, так что, для меня это в новость

@AK В любом случае меня интересует логика и безопасность, две необходимые вещи, будет отлично если мусор будет удаляться пхп, тогда вообще в принципе проблем не должно быть, надеюсь ничего не упустил

Ну так в php дофига движков -- просто попробуйте открыть код любого из них, просто посмотрите как сделано.

Всё бессмыслица какая-то, положить id пользователя в сессию и периодически удалять мусор вполне достаточно в 95% случаев

вот, да.

@andreymal Я может чуть запутался, я использую сессию типа как массив данных, а кукисы, для проверки на авто-авторизацию (автологин)

@andreymal То есть сейчас, я хочу понять, по какому принципу должен работать автологин

@AK ?

Лично я просто периодически продляю сессию на желаемый срок (правда, я это делаю не на php, а для php я что-то не нагуглил адекватного способа продления сессии)

Но да, некоторые сайты действительно добавляют куку со случайным идентификатором, по которому потом делается автологин

@andreymal Ну вот, я такое реализовал, нужно теперь понять какие сесии удаляются и как часто, к примеру у меня при заходе на страницу, создаются почему-то по две сессии, одна пустая, другая уже с данным. Удалить можно только ту которая с данными, а вот та пустая, ее удаляет мусорщик ? Я просто не пойму как он работает

@andreymal Удается файлы сессий с 0 kb ?

Это пусть A K расскажет, я в детали работы php-сессий не погружался)

@andreymal Ок, буду в общем эксперементировать с мусорщиком, чтобы понять как он работает и удаляет. А то, допустим, если много людей, удаляться ничего не будет, так там столько нагенерирует сессий..

@webstackoverload "Много" людей это сколько? Тысяча людей одновременно на сайте и вас волнует 2000 файлов в каталоге сессий?

Или у вас 10 тысяч сессий на сервере?

@AK У меня на сервене ничего нет, потому что нет сервера. Я просто думаю за будущее, чтобы не сделать так, чтобы это потом только навредило. Как бы избегают наверно "элементарных" ошибок.

@AK Буду экперементировать с мусорщиком, хочу понять как он сессии и какие именно удаляет

@webstackoverload В данном случае надо понимать, что когда будут значения по 100 тысяч сессий на сервере -- это будет уже пора ставить второй сервер и ваша схема с идентификатором сессии может тупо оказаться нежизнеспособной, ибо сессия на одном сервере а пользователь зашёл на второй.

Ну то есть не будет у вас миллиона файлов в каталоге сессий

Потому что на подходе к этому порогу у вас давно поменяется подход.

А на тысяче сессий переживать за тысячу файлов - просто глупо. Экономия на спичках.

Вы откройте какой-нибудь код вордпресс... и удивитесь, что там нет никаких сверхизысканных подходов и ничего, работают миллионы сайтов на нём.

phpbb, codeigniter, joomla... господи, да что угодно, хоть битрикс возьмите. В битриксе (не к ночи будь помянут) можете посмотреть как сессии на sql-сервере хранятся, там ещё лет 10 была такая фича.

@AK Открывал, да, но сырой wordpress, слишком мало подвижный, есть просто спрос на малкие задачи, которые легче решать, самому, чем переделывать или создавать какие-то до плагины.

Место хранения сессий всегда можно изменить, хоть на sql, хоть на redis, так что, думаю, это не тот момент, о котором стоит переживать

@andreymal Я так и сделал через php ini указал патч куда их сохранять, но может есть какие-то альтернативы, но это такое. Меня щас мусорщик беспокоит, интересно, как он работает. Ну а в остальном, с автологином, думаю разберусь. Кстати АК говорил использовать PHPSESSID вместо генерации, а если его украдут ? А так выходит я могу генирировать ключ в кукисы к примеру из USER AGENT емайла или айпи пользователя, а потом

к примеру часть расшифровывать и сверять, допустим, если юзер зашел с кукой, но сменил себе USER-AGENT то сессия удалится ! потому что при дешифровки ключа user-agent не совпадут

@webstackoverload если его украдут, то и user agent тоже украдут, а айпи и так у пользователя регулярно меняется, так что это всё бессмыслица

Таким образом, некого своего рода, защита будет и более уникализированная и безопасная авторизация

@andreymal Просто нужно сделать как я понял больще привязок, но да, смотря как украдут еще

@webstackoverload PHPSESSID достаточно, всё остальное или украдут вместе с ним, или порушит в хлам юзерфрендли

Если привязываться к юзер-агенту, то с каждым обновлением браузера автологин будет слетать к чертям, что на корню губит всю идею

@andreymal Значит можно привязать к емайлу, так как это тоже уник айди в базе будет

@webstackoverload емайл тоже совершенно не проблема украсть, к тому же некоторые пользователи сами его публикуют везде

@andreymal Идея еще в том, чтобы если и украли, то это была целенаправленно, а не массого

то есть украли какие-то конкретные ключи каким-то конкретным путем

@webstackoverload массово и PHPSESSID тоже не украдут

Куда более вероятно, что массово украдут логин и пароль, потому что пользователь дурачок и сам введёт их на фишинговом сайте. Не о том переживаете вообще

В любом случае, я всё равно не знаю способов массового угона кук в целом и PHPSESSID в частности. Если настроить HTTPS и врубить HttpOnly куки с флагом Secure, то никуда они не денутся

А если вдруг пользователь запустит вирус на своём компьютере, то этот вирус тупо прочитает пароль прямо с клавиатуры, и переживать за куки абсолютно бессмысленно в таком случае

@andreymal За такие атаки я не переживаю, массого в будущем да, ибо подвергать что-либо таким ошибкам, опасно. В общем примерно все понятно. Буду дорабатывать, потом уже добавлю - уберу не нужное и потестирую в работе.