Запрос авторизации при неактивности > 1 дня

Цитата (micros):

перед тем как развешивать ярлыки о профессионализме или его отсутствии

Это вы себе написали? 

Hungry_Hunter, вопрос был задан об авторизации, а Елена говорит об обмене данными=) О чем тут спорить?=) Если бы вопрос был задан по например репликации данных, то да, Елена все верно говорит о сессиях при репликации=) Или Если бы вопрос стоял о обмене данными по API, опять Елена была бы права в понимании сессий=) 
ссылка  я о вас=) я ниразу на этом форуме никому не сказал профи он или нет, а вы в этой теме два раза это написали)

micros,  ну-ну... 
Цитата (micros):

floppox, пфффф. Ну да, куда же мне до вас, до профи=)))

Цитата (micros):

ну я так то скажу, тут всем кто прочитает топик, и кто разбирается в кодинге, поймут кто профи, а кто нет=))

Цитата (micros):

свой профи опыт не самом хорошем цвете показываете=)))

Цитата (micros):

Кому то может быть обидно жеж=) я не про себя, я свой и ваш уровень вижу

Это я все писала, да?

floppox, а где я писал что вы не профи?  тут сказано, что люди сами поймут где профи а где нет. Я не берусь оценить ни Вас, ни кого либо еще на этом сервисе=) Себя могу оценить, могу оценивать своих коллег с которыми работаю, критиковать могу, так же как и меня критикуют=) и это супер для проф развития) а ведем мы не много не мало а парочку очень высоконагруженных проектов на кластерной системе, с репликами данных, и поверьте на слово, о сессиях разного рода знаем не мало=) может и не все, мы же не гуглы=)

И да, я не в коем случае не хотел Вас обидеть, если вам показалось обратное, прошу прощения=) Суть мною всего написанного, сводится к тому что сессия авторизации может хранится сколько угодно, где угодно, и тд, и срок хранения ее, можно регулировать, о чем спросил топикстартер=) Всего лишь относительно к сессиям авторизации=)

Цитата (micros):

Себя могу оценить, могу оценивать своих коллег с которыми работаю

А я вот, реально НЕ МОГУ. 

Цитата (micros):

а ведем мы не много не мало а парочку очень высоконагруженных проектов

С чем вас и поздравляю, но это заслуга проджект-менеджера.

floppox,  у меня нет прожект менеджера=))) я не студия=) а коллеги мои такие же фриланцеры как и я=) нету у нас ни сайтов с рекламой наших услуг, ни менеджеров, ни тем более директоров=) заказы - это клиенты, их друзья, студии которые передают на обслуживание=)
Мы с коллегами работаем по принципу взаимозаменняемости, что бы если кого то нету в сети, было кому помочь клиенту=)

Цитата (micros):

И да, я не в коем случае не хотел Вас обидеть, если вам показалось обратное, прошу прощения=)

Я не обиделась, но в извинения не верю. 

Цитата:

Я не обиделась, но в извинения не верю. 

напрасно, я искреннее. Ну а раз не обиделись, то вообще добре)

Цитата (micros):

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

Авторизация - может (посредством иных механизмов, ВНЕ сессии).
Сессия - нет. 

floppox, ок пусть будет так=) но мы по прежнему будем хранить сессий в REDIS, по средствам вот такого конфига php.ini
session.save_handler = redis
session.save_path = ссылка888
без использования каких либо инных механизмов в виде контроллеров на php, работая при этом с переменной глобальной $_SESSION

micros, и зачем, когда пользователи не онлайн? Это не логично (если речь идет о неделях, как вы говорили выше) 

floppox,
1 для того что бы юзеры не разлогинивались сами по себе, и сессия была жива столько сколько это нужно админу сайта, увы файловое хранение при больших милитах времени хранения, со временем начинают существенно тормозить работу сайта
2 Скорость работы REDIS выше чем хранение в файлах, даже если хранение в файлах настроить правильно с групировкой, а это важно когда мы имеем 100500 открытых сессий, которые нам нужно держать пол года.
Речь идет о неделях на CMS и магазинах, хоть и не всегда некоторые просят день, вторые год=)
Я вприницпе говорил о сервисах которые долго держат сессию, таких как соц сети, яндекс/гугл, сео сервисы, теже биржи, включаю и нашу любимую weblancer. 
Принципиален не вопрос сколько хранить по времени, а вопрос сколько пользователей прийдется хранить, и только потом какое время.

А еще я говорил о том что сессию можно хранить где угодно, без каких либо дополнений, стандартно, и время жизни установить можно сколько угодно даже при хранении в файлах для PHP. 
Время хранения сессии в PHP задается значением session.gc_maxlifetime
Поэтому
Цитата:

Суть мною всего написанного, сводится к тому что сессия авторизации может хранится сколько угодно, где угодно,
Авторизация - может (посредством иных механизмов, ВНЕ сессии).
Сессия - нет. 

ваше суждение, извините но неверно
ну или параметры session.gc_maxlifetime session.save_handler session.save_path
неправильно названы, и это на самом  не сессии, а какие то мифические инные механизмы
floppox,
1 для того что бы юзеры не разлогинивались сами по себе, и сессия была жива столько сколько это нужно админу сайта, увы файловое хранение при больших милитах времени хранения, со временем начинают существенно тормозить работу сайта
2 Скорость работы REDIS выше чем хранение в файлах, даже если хранение в файлах настроить правильно с групировкой, а это важно когда мы имеем 100500 открытых сессий, которые нам нужно держать пол года.
Речь идет о неделях на CMS и магазинах, хоть и не всегда некоторые просят день, вторые год=)
Я вприницпе говорил о сервисах которые долго держат сессию, таких как соц сети, яндекс/гугл, сео сервисы, теже биржи, включаю и нашу любимую weblancer. 
Принципиален не вопрос сколько хранить по времени, а вопрос сколько пользователей прийдется хранить, и только потом какое время.

А еще я говорил о том что сессию можно хранить где угодно, без каких либо дополнений, стандартно, и время жизни установить можно сколько угодно даже при хранении в файлах для PHP. 
Время хранения сессии в PHP задается значением session.gc_maxlifetime
Поэтому
Цитата:

Суть мною всего написанного, сводится к тому что сессия авторизации может хранится сколько угодно, где угодно,
Авторизация - может (посредством иных механизмов, ВНЕ сессии).
Сессия - нет. 

ваше суждение, извините но неверно
ну или параметры session.gc_maxlifetime session.save_handler session.save_path
неправильно названы, и это на самом  не сессии, а какие то мифические инные механизмы

Цитата:

micros, и зачем, когда пользователи не онлайн? Это не логично (если речь идет о неделях, как вы говорили выше) 

вопрос не стоял зачем, вопрос стоит возможно ли, я говорю можно и нужно, вы говорите нельзя. Офф ддокументация по php тоже говорит что можно. Вот и все

Цитата (micros):

Скорость работы REDIS выше чем хранение в файлах

Это ослу понятно. Но разве оно бездонное?  

Цитата (micros):

вопрос не стоял зачем, вопрос стоит возможно ли, я говорю можно и нужно, вы говорите нельзя.

Возможно и попугая научить в унитаз какать.

floppox, ахахах=)))) что уже ненужны "инные механизмы"?
Елена о чем вы? Ненадо учить php, достаточно просто настроить=))))) Он и так умеет=)))
Цитата:

Это ослу понятно. Но разве оно бездонное?  

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

Вы сначала говорили что это нереально, потом говорить уже что реально но не логично, потом опять говорите что можно только "инными механизмами", а теперь совсем на попугаев перешли=)

Елена - сессии можно хранить где угодно и сколько угодно админу. Без "Научить", просто настроить! Или по вашему все таки нельзя?

Цитата (micros):

ваше суждение, извините но неверно

Ок, технически, да сессия может храниться. Но это баг. Баг, которого не должно быть. Сессия ДОЛЖНА в идеале существовать ровно столько сколько сайт открыт в браузере. Так как это именно НЕВОЗМОЖНО надежно реализовать, ввели понятие времени жизни сессии, и был установлен стандарт дефакто в 15 минут. 
Заметьте, вопрос. где хранить, я вообще не затрагиваю, потому что он не принципиален в данном контексте. 
В идеальном случае сессия перестает существовать в момент закрытия браузера. Но так, как существует необходимость помнить пользователя, информация о сессии сохраняется в постоянном хранилище, отличном от хранилища сессий. Когда пользователь открывает сайт в следующий раз, начинается новая сессия, которая создается с учетом ранее сохраненных данных. 
Именно так выглядит классический, выверенный годами и куда более крутыми специалистами, чем можно найти на этом сайте.
Возможность пользователя при повторном открытии браузера попасть ровно в ту же сессию, что и в прошлый раз, является принципиальным багом технологии. 
Вы воспользовались этим багом и хакнули общепринятый стандарт, чем, в частности, упростили себе задачу (не надо писать код консервации). Возможно, на данном этапе это решение является оптимальным, и как любое, выполняющее свои функции, решение, имеет право на жизнь. Но это не делает его логически верным, и тем более, не дает оснований для заносчивости. 
Дай бог, чтоб не вылезли боком те же проблемы безопасности и другие подводные камни. 

Цитата (micros):

Вы сначала говорили что это нереально, потом говорить уже что реально но не логично, потом опять говорите что можно только "инными механизмами",

Цитаты приведите, пожалуйста.

floppox, опередили меня, примерно тоже самое хотел написать

Цитата:

Ок, технически, да сессия может храниться. Но это баг. Баг, которого не должно быть. 

этот баг, как вы называете присутствует и в PHP7, мало того, он еще и усугублен добавлением memcached, mysql. и вопросов связанных с безопасностью тут вообще нету.  Ничего я не хакал
Разработчики MAGENTO, BITRIX, OPENCART 2 (после обновления, в 1,5 вретке не было БАГА  ),  и других крупных CMS, да больше, все фреймворки на уровне "инных решений" с коробки умеют хранить где угодно сессии и сколько угодно. 
ПОлучается все вокруг хакают какие то там стандарты походу.... 

По цитатам, пожалуйста перечитайте =) И увидите как мнение ваше меняется=) от невозможно до БАГА, и безопасности

Цитата (micros):

этот баг, как вы называете присутствует и в PHP7, мало того, он еще и усугублен добавлением memcached, mysql. и вопросов связанных с безопасностью тут вообще нету.  Ничего я не хакал

Сразу три принципиальных ошибки в одно предложении. Но я прислушаюсь к мнению Hungry_Hunter, что пытаться вас убедить бесполезно.
Цитата (micros):

пожалуйста перечитайте =) И увидите как мнение ваше меняется=)

Если бы вы пытались понять сказанное, а не найти аргументы в пользу своего мнения, то восприняли бы все немного иначе. 

Hungry_Hunter,
Цитата:

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

Видите как вышло, оказывается я понимаю, но это БАГ, и хак стандартов. Но это возможно, и я понимаю получатся=))))))

Елена, правильно спорить не о чем, я работаю по стандартам которые общеприняты, которые регулярно внедряются в другие программные решения, ХАКАЯ стандарты багами - как вы говорите.

Стандарты это когда общепринято, и используется. Всеми крупными фрейворками и CMS принято и используется.

Значит вариантов аж два, или мы все кто использует эти механизмы - не правы, и это корень зла, или второй вариант Вы Елена вместе с 
ссылка придумали себе свои стандарты=)))

Вы ни одного аргумента не превели, только какую то виписку об обмене данными. Я же разжевал, и примеры использования привел=))) и я тут прав, как и разработчики крупных проектов, CMS и фреймворков. Используют и будут использовать без ущерба безопастности! Распространять баг по вашенски)))))

Цитата (micros):

Видите как вышло, оказывается я понимаю, но это БАГ, и хак стандартов. Но это возможно, и я понимаю получатся=))))))

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