Хранение данных пользователя

Я вам уже советовал перечитать топик сначала? кажется, да...

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


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

-----
Чем больше узнаю, тем больше я не знаю.

PS
обращаться к этой табличке нужно будет при входе, выходе и удалении пользователя

(Отредактировано автором: 19 Августа, 2013 - 20:53:29)

-----
ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)

Вот в данном контексте лично мне он как раз и не понятен. Если ты такой умный, то объясни, что такое в данном контексте "сессия", если это не кука, не содержимое куки, и не файл, то тогда что?
А зачем засовывать туда весь класс?

А я например вижу. Как тут сказали, "тем кто в теме" разница очевидна. Ссылочку то почитай, там как раз разжевано.
(Добавление)
Ты теоритизировать то брось, а просто прикинь как это будет работать в реале. Если грубо, ты формируешь страничку admin.php , на которой выводишь логин пользователя/(или что ты там хочешь), и рядышком кнопочку "удалить". Я правильно поняла твою задумку?
Теперь опустимся до реальной жизни. Кнопочка будет снабжена ссылочкой, типа:
/user_del.php?UID=$UID&SID=$SID.
Сразу вопрос. Ты так печешься о безопасности. На сколько такая страничка будет безопасна в реальной жизни? Если ты передаешь только один параметр, то тебе придется по любому получать второй из БД Это первое обращение. Что бы удалить пользователя, из BD, тебе придется дернуть и саму БД. Это уже второе обращение. Ну и каким-то образом прибить саму сессию, это уже третье обращение. Даже если ты передаешь все два параметра, обращений будет ДВА, а ты твердишь, что одно.
Мой же вариант, более безопасен. В user_del ты передаешь только $SID, и на странице admin, ты в открытом виде выводишь ТОЛЬКО $SID.
Второй момент. Ты должен как-то защить вызов user_del от злоумышленника и робота.



При открытии сессии, указывается время ее жизни. Если сессия жива после указанного времени, это говорить только о рукожопости админа, настраивавшего сервер.
Мелкий: Кста, твоя ссылка не открылась.

(Отредактировано автором: 20 Августа, 2013 - 00:48:58)

Передаем только userID. Получили, зачитали sessID, запустили сессию, очистили ее, удалили юзера из БД. Два запроса, где вы третий выкопали, я не понимаю.
И где я говорил про один запрос? Я специально пролистал назад, не нашел.
К тому же, что вы так этих двух запросов к базе при удалении пользователя боитесь, что готовы на каждый запрос дергать файл и искать в нем айдишник?.. Вы что на столько часто пользователей удаляете?.. Я нет. И если и будет пара лишних запросов, как вам кажется, к базе за неделю, так это вобще ничего.

Я так погляжу, у вас все рукожопые, и админы всех серверов, и программисты из гугла. Так что ж вы с нами, рукожопыми, тут возитесь, а?!
По теме, кем и куда указывается? И советую почитать, как организован GC в PHP, может поймете наконец, что сессия может и полгода пролежать, а потом благополучно будет возобновлена.

-----
Все возражают против того, что я гений, хотя никто еще так меня не назвал. - Орсон Уэллс

Белка такая белочка )

-----
Чем больше узнаю, тем больше я не знаю.

Товарищи, ну тема так и не раскрыта. Как поддерживать авторизацию и корректно удалять/банить пользователя? При этом не трогая БД при простой навигации по сайту.

Я вот что надумал.
В таблице пользователей есть поле session.
При входе пользователя на сайт, пишем в это поле его session_id.
При навигации по сайту не трогаем базу - не нужен нам его session_id
Если нужно удалить пользователя или изменить его права, то у нас есть его session_id

Далее:
Пользователь ушел с сайта. Неважно как - нажал кнопку выйти или просто закрыл окно. Ничего не делаем с его session_id.
При следующем входе обновляем поле session. Если пользователь входит по куке, то делаем тоже самое - обновляем session_id в базе.

Я ничего не упустил?
(Добавление)
В догонку еще такой вопрос, немного не по теме.
Озадачился я вчера реализацией статуса online, offline.
Забабахал в таблице юзеров поле - status (0 и 1). А потом понял, что лоханулся. Начал гуглить на эту тему. Оказывается поле status в базе совершенно бессмысленно, так как пользователь может просто закрыть браузер и все - кто обновит поле status?
Неужели нет иного способа реализации статуса кроме записи и сравнения времени? Ведь это опять запрос к БД при каждом запуске скрипта.

Например нужно сделать некий модуль, который выводит 10-20 юзеров online. Или выводить список всех пользователей у каждого из которых есть статус - online/offline. Ну как на форуме вообщем.
Здесь на форуме я так понял тоже по времени. Чтож это, при каждом обновлении страницы/переходе - запрос к БД и сравнение временных меток?

-----
ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)

в точку (см.аватар)

(Отредактировано автором: 20 Августа, 2013 - 17:36:37)

-----
Правильный вопрос - уже половина правильного ответа!

p.s. индусы повсюду, будьте осторожны!

самостоятельно реализовать механизм сессий в базе

LIME
Объясните мне, что значит сессии в базе, что понимается под этим?
В базу пишется session_id, в базу пишутся сессионные данные... так? Зачем? А как удалять данные при выходе пользователя, если он просто закрыл окно?

Чем плох мой вариант выше? Цель ведь достигнута - корректно удалять пользователя и обновлять его права. В базу нужно лазить только при необходимости, а не при каждом запуске скрипта. А так пусть сессиями рулит php. Нам нужен лишь session_id< чтобы очистить или обновить сессию

-----
ПЫХ тут - ходи туда, прежде чем писать сюда (толку больше будет)

После продолжительного холивара у меня вопрос: чем мой вариант-таки не устроил? Или все же ТС пишет авторизацию на веримегахайлоад, на котором один запрос к базе при одном обращении к скрипту - непосильный груз?

-----
Пессимисты пользуются die(), оптимисты - exit()

механизм полностью реализуй
напиши класс Session
не пользуйся встроенным session_start вообще

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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

нет ...он пишет авторизацию в учебных целях
и правильно делает
и так полно тех кто пишет "лишь бы работало"

LIME, а мой вариант по-вашему, "лишь бы работало"?

-----
Пессимисты пользуются die(), оптимисты - exit()