Сохранение ассоциативного массива в строке

[Romashov]

Дата, имя пользователя, плюс откуда он пришёл + браузер.
Это не постоянные данные о пользователе - а данные о посетителе [сеансе], которые фиксируются для анализа статистики посещений + кто онлайн

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

 

[Фанат]

Я прекрасно разбираюсь

Ладно, ты свободен.
что-либо объяснить можно только человеку, который этого сам хочет.

 

[Romashov]

Нет, я хочу объяснений.
Если вы сможете предложить более глубокую оптимизацию, я буду благодарен. Сейчас я считаю, что у меня достаточно удачная схема. Просьба: покажите ошибки в ней!

 

[Фанат]

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

плюс, почему-то эта система противопоставляется сессиям, при том, что разницы никакой нет. Сессия ставит куку - и твоя система ставит куку. Сессия увеличивает адрес - и твоя система таскает хэш.

И пльлм, меня несколько настораживает слышать от одного и того же человека заявления

хранение SESSID в адресе накладывает ограничение: браузер закрыт, новая сессия, новые настройки, новый юзер.

А потом он сам же говорит про хэш.
Каша.

Каша меня вообще очень расстраивает.
Сначала пишем что идентификация идет по имени, при том, что в протоколе НТТР нет такого понятия, как "имя пользователя". потом узнаем, что это все-таки, кука.
Сначала читаем про то, что без кук юзер будет таскать за собой хэш, но опять же - ни слова о реализации этого механизма

 

[4m@t!c]

2 Фанат

Вместо того, чтобы переписывать обработчик сессий, как это делают многие

А для чего переписывают обработчик сессий, что в нем изменяют?

 

[Фанат]

способ хранения с файлов на базу

 

[Romashov]

To: Фанат
Я говорю про таскание хэша в URL только в случае авторизованного пользователя+не имеющего кукисов.
Потому что здесь ничего другого не придумаешь. Нет вариантов, использую как неизбежность.

В других случаях хэша в строке не будет.

Причём, если сеанс не закрыт, а пользователь закрыл браузер, то снова авторизировавшись он получит тот же хэш, с теми же временными настройками отображения.
Это реализуется выборкой из таблицы `хостов` этого пользователя не раньше time()-$script_options["session_time"]
И дальнейшая работа с этим заходом.

Серьёзно извиняюсь за кашу, если такая возникла.

 

[4m@t!c]

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

 

[SiMM]

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

 

[Romashov]

To: 4m@t!c
Случай использования хэша особый - только если нет кукисов и пользователь зареген. Это не более 10% всех вариантов.
В БД для IP адреса поле есть, поэтому подключить проверку не составит труда. Спасибо. Совет хороший.
To: SiMM
Использование "обычных сессий" - в данном месте не очень удобно, т.к. это может вызвать некорректную работу с поисковиками, а также неудобства (я теряю контроль на ними, т.к. они настраиваются хостером - время хранения и доступ к ним).
Мой механизм не хуже стандартного (в нём есть всё, что мне нужно и ничего лишнего), но он лишён вышеуказанных недостатков. Я смогу контролировать время сеанса, подчищать, пользователи смогут закрывать браузер, не боясь потерять временные данные (а сеанс продолжается),

 

[4m@t!c]

Я смогу контролировать время сеанса

Ты не контролируешь время сеанса, ты эмулируешь его работу.
Ты переживаешь за нагрузку на БД

Потом из этой табл. придётся выборки производить по пользователям - ещё лишняя затяжная нагрузка.

причем, ты начинаешь ее грузить запросами авторизации... Почему не пользоваться сессиями, и четко разделить сеаснсовую информацию и инофрмацию о Юзере, как таковом...??7как правильно заметил Фанат - каша. Каша из-за того, что ты изобретаешь велосипед, хочешь сделать изобретение лучше, чем уже изобретено. ЗАЧЕМ?

 

[Фанат]

В других случаях хэша в строке не будет.

сессии работают точно так же.
А ты рассказываешь, что

Я прекрасно разбираюсь

Вот это и вызывает недоверие к твоим выкладкам.

Причём, если сеанс не закрыт, а пользователь закрыл браузер, то снова авторизировавшись он получит тот же хэш, с теми же временными настройками отображения.

ты уж определись - временные это настройки, или постоянные.
Если временные, то с какой стати он получает их заново?
Если постоянные, то нет проблемы - достаем при входе.

Что-то ты тут явно не догоняешь. Ты приписываешь своему механизму какие-то мифические достоинства перед механизмом сессий. При том, что я вижу как минимум два недостатка:
1. Хэш надо таскать вручную.
2. Понятие сессии у тебя как таковой отсутствует. То есть, при явно завершении сессии (закрытии браузера) она у тебя не завершается.

 

[SiMM]

Автор оригинала: Romashov
Использование "обычных сессий" - в данном месте не очень удобно, т.к. это может вызвать некорректную работу с поисковиками, а также неудобства (я теряю контроль на ними, т.к. они настраиваются хостером - время хранения и доступ к ним).

Я всё думал - даст ему кто эту ссылку или нет. PHP FAQ: Сессии. Подробное описание работы и объяснение механизма., [m]ini_set[/m], .htaccess в конце концов.

Мой механизм

Весь твой механизм - ни что иное, как [m]session_set_save_handler[/m]

не хуже стандартного

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

 

[Фанат]

SiMM, на самом деле, смысл есть.
стандартный механизм - не идеал. И рацуиональное зерно в РЕШЕНИИ Рромашова есть.
Вот только я не люблю, когда решение получается не из реальных фактов, а из выдуманных.

 

[SiMM]

Не вкуриваю Всё, что он описал - имхо вполне решается без велосипеда. Сессии может и не панацея от всех бед, но пока с такими бедами сталкиваться не приходилось - может опыта маловато

 

[Romashov]

ты уж определись - временные это настройки, или постоянные.
Если временные, то с какой стати он получает их заново?
Если постоянные, то нет проблемы - достаем при входе.

Временные и потому что сеанс посещения (согласно настройкам) не закончился.

2. Понятие сессии у тебя как таковой отсутствует. То есть, при явно завершении сессии (закрытии браузера) она у тебя не завершается.

Понятие сессии присутствует, но в изменённом смысле: сессия - это промежуток времени, в течение которого пользователь может беспрепятственно пользоваться ресурсом, временными (сеансными) настройками, даже закрыв браузер.

Я всё думал - даст ему кто эту ссылку или нет. PHP FAQ: Сессии. Подробное описание работы и объяснение механизма.,

Через это я уже прошёл, прочитал, разжевал не один раз. Противоречий с тем, что я делаю не обнаружил.