Все, кому я задавал этот вопрос, подтвердили и отвечали бурно и жутко ругались, что писали выдающийся пост и ... бац, все потеряно. Я сам недавно так потерял большой пост и не стал переписывать
до сих пор жалею текст.Мы быстро учимся на болезненном опыте и большинство уже выработали правило, что любые большие сообщения копируют в буфер, прежде чем нажать кнопку формы...
И не думайте, что я говорю сейчас про продукты 1С-Битрикс, это свойственно всем веб-приложениям.
Сегодня я хочу рассказать, как мы решили эту проблему и почему теперь вы станете добрее - потому, что вы и ваши клиенты не будут больше сталкиваться с такими проблемами при работе с продуктами нашей компании
Итак...
[spoiler]
Что такое сессия и зачем вообще эту гадость придумали?
Сессии придумали веб-разработчики, чтобы идентифицировать своих посетителей. Придумали уже давно и успешно пользуются во всем мире.
Каждый раз, когда вы заходите на любой веб-сайт, системой для вас придумывается уникальный номер сессии и страница вам отдается именно с этим уникальным номером. И все последующие ваши обращения к этому сайту идут уже с этим идентификатором сессии. Так веб-разработчики научились понимать, что все запросы идут именно от вас, а не от кого-то другого.
Т.е. сессия - это весь ваш сеанс работы с веб-сайтом от первого входа на сайт и до завершения работы с сайтом.
Вот тут как раз и возникает проблема у разработчиков. Как определить, что сессия пользователя завершена?
Вы же можете пойти кофе пить, покурить или будете долго писать сообщение в блог или форум.
Пользователи возмущаются. Почему вообще нельзя сделать сессию бесконечно, если вы, веб-разработчик, не можете без нее делать веб-сайты?!
Есть две основные причины: производительность и безопасность. Если хранить долго сессии, их будет много и все начнет тормозить. Если пользователь авторизован, он авторизует именно сессию, а безопасность требует завершать неактивные сессии. В общем, не получается хранить долго.
Но если вас это улыбнет, большинство веб-разработчиков даже не знают, как работают сессии, и что они используют сессионные куки и как они передаются
Я не шучу. Многие веб-разработчики начали учиться программировать сайты, когда сессии уже были придуманы, и воспринимают это как данность. А ведь когда-то мы в php3 их сами эмулировали Даже сейчас завальный вопрос для начинающих сайтостроителей «Как работает сессия, нарисуйте сеанс?»В общем сегодня сформировалась практика в сообществе, что сессия пользователя длится 20-30 минут. Т.е. если вы открыли страницу сайта и 30 минут не переходили на другие страницы сайта и не получали новые страницы в этой сессии – веб-сервер просто решит, что вы ушли и завершит вашу сессию даже не задумываясь, пишите вы пост в блог или вернулись с перекура и заполняете важную форму.
Что же делать, я ненавижу когда истекает моя сессия?!
Неоднократно я видел попытки решить эту проблему.
Обычно делают обработку форм так, чтобы даже если сессия истекла, пользователь мог ввести логин и пароль и данные в форму поступили бы в полном объеме. Мы рассуждали так же и делали такие обработки в форумах, блогах и других формах. Но как метод это себя зарекомендовало не очень хорошо. И мы не все могли уследить и, что самое главное, наши партнеры вообще об этом не успевают задуматься. Да и даже если все сделано хорошо по этой методике, пользователь видит первое сообщение, что сессия истекла и уже хватается за сердце и гневается на вас.
Другой способ – предупреждать пользователей, что сессия истекла. Веб-сервер, когда создает страницу, знает длительность сессии и при приближении к ее завершению может предупреждать пользователя.
Недавний пример – Альфа-Клик. Банковский сервис крайне нуждается в соблюдении безопасности работы пользователя. Когда сессия близится к завершению, появляется такое сообщение.
Если вы за компьютером и что-то делаете на странице, то быстро быстро нажмете на кнопку, глубокий выдох и мысленно говорите спасибо Альфа-Клик, что он не заставил вас гневаться.
Живая сессия - мы сделаем вас добрее, но вы этого не узнаете
Недавно мы решили найти системное решение этой проблемы, чтобы все сайты на нашей платформе стали более удобными для посетителей.
Напомню разработчикам, что когда мы создаем страницу, мы знаем длительность сессии и время создания этой страницы. Помните, что управляется это время модулем безопасности, причем независимо от настроек веб-сервера.
В браузере пользователя мы незаметно для него начинаем обратный отсчет. За несколько минут до завершения сессии мы включаем голову и смотрим, жив он или нет. Проверяем, когда были последние нажатия на клавиатуру, клики и движения мышки и … мы незаметно для пользователя продлеваем сессию если он еще жив. Т.е. мы шлем запрос к веб-серверу, чтобы сервер ЗНАЛ, что этот посетитель еще с нами. Сессия продлевается на сервере и никаких сообщений пользователям не показывается.
Живая сессия - живет столько, сколько пользователь работет с сайтом.
Если вы не проявляли признаки жизни больше длительности сессии, не двигали мышкой в окне браузера, не пишете текст, не кликали или не нажимали сенсорный экран, в общем, если вы забыли про эту страницу – мы покажем вам такое вот сообщение.
Это сообщение покажется как в административном разделе, так и на публичных страницах сайта.
Цель этого сообщения – просто проинформировать посетителя о том, что его сессия работы с сайтом завершена. Конечно, мы не будем показывать сообщение, если вы ходили по сайту, но не авторизовались. Если пользователь при авторизации отметил "запомнить меня", он так же сможет восстановить сессию. В общем, все будет работать как и ранее.
И, конечно, вы можете управлять живой сессией в настройках главного модуля.
Я немного упростил для вас изложение. Реализация получилась довольно сложной. Мы планировали сделать за пару дней, когда придумали решение. Но фактически Вадиму Думбравану пришлось потратить две недели на сочетание идеи с системой безопасности и тесты на безопасность, на обход проблем на хостингах, совместимость и тестирование.
После выпуска бета-версии и пробной эксплуатации, мы решили дополнить механизм попыткой восстановления авторизация и только если она оказывается неуспешной, тогда выводить сообщение. Это делает систему еще более удобной и ориентированной на пользователей.
Сейчас реализацией мы очень довольны
надеюсь и вам она понравится.Доступно решение будет начиная с версии главного модуля 9.5.7, который пока доступен в режиме бета-тестирования. Немного погоняем и выпустим всем для работы.
Живая сессия сделает нас добрее незаметно для нас
чего тогда нас в форуме томили, мы то думали вы только этот div в обновлениях выпустили
Чтобы сделать вас добрее
Кстати, мы ни разу не видели подобной реализации. Правда не сильно и искали, но среди приложений, которые знаем, не встречали. Кто-нибудь видел подобную идею, реализованную ранее?
Но может все же галочку "Показывать пользователям сообщение об окончании сессии" не стоит ставить всем при апдейте по умолчанию?
Ну правда, это не очень здорово добавлять что-то в публичке без разрешения клиента.
P.S. речь идет исключительно про публичную часть, в админке, думаю, можно включать всем по умолчанию. Кстати, добавление отдельной галочки для публичной части тоже не помешает.
Наоборот, считаю что надо всем его принудительно включить.
Представьте, что я действительно отошел пообедать или чего то там еще сделать. Больше чем на 30 минут. У меня сессия "протухнет" и я вынужден буду все таки как то оперировать с теми данными, которые уже ввел.
Копирование - половинчатое и неполноценное решение хотя-бы в силу того, что полей может быть не одно. Кроме того часто пользователи хранят пароли и логины в разных местах, из которых достают так-же методом копи-паста, соответственно сценарий:
1) Вы отрубили сессию пользователю.
2) Показали сообщение (похвально, но сообщение "ни о чем" в большинстве случаев, кроме банка разве что)
3) Пользователь скопировал в буфер обмена данные и следующим шагом
4) вы предложили ему еще раз залогиниться. Ура!
5) В этот момент пользователь лезет в другое место и например копипастит пароль в тот же буфер обмена, затирая данные, которые там были до этого
результат понятен - вся работа (например статья) потеряна.
Бинго!
Это только один вот такой сценарий. Можно еще придумать. Понятно, что при этом пользователь может скопировать ВСЕ поля например в текстовый файл (с потерей форматирования) или например в Word (c последующими глюками с обратным постингом). Или поставить себе утилиту с поддержкой стека копи-пастов. Тоже решение.
НО!
Все это костыли из-за того, что разаботчик НЕ подумал о том, что человеку пофигу сессия и прочее. Мне блин работать нужно!
Есть несколько пришедших мне в голову вариантов:
1) Не убивать сессию вовсе, если открыто соединение (открыто окно в браузере, есть интернет).
2) Сессию можно прибить, но при постинге формы нужно сохранить ВСЕ данные, запросить у пользователя пароль и собственно завершить действие, которое пользователь произвел, нажав на кнопку
Понятно, что бывают исключения в виде например банков. Но это исключения, которые сугубо подтверждают правила. В случае с банками сессия прерывается не из-за наших с вами заморочек по поводу торможения или огромного кол-ва сессий. Думаю, что эти проблемы как раз решены. Там причина именно в безопасности. То есть та причина, которая понятна любому пользователю.
HTTP протокол относится к так называемым stateless протоколам, у которых нет понятия сессии или сеанса. Это делает его очень простым и быстрым, но и создает проблему, о которой мы с вами и говорим. Так что не выйдет сделать без сессии.
Мы это уже делаем, я писал выше. Если вас беспокоит сообщение, можете отключить его появление.
Но цель сообщения как раз в том, чтобы предупредить пользователя, что возможны проблемы.
И все же еще раз обратие внимание, сообщение появляется только тогда, когда сессия реально истекла. Если вы просто сидите на странице и что-то с ней делаете, мы продлим сессию и ничего не покажем пользователю. Раньше так не делали и проблем было намного больше не зависимо от того, знаете вы о сессия или нет.
Кстати, ответ писал между долгими звонками
Пропустил несколько моментов
Я это знаю и не ставлю под сомнение. Видимо неправильно выразился. Наличие сессии оправдано. Этим инструментом нужно просто правильно пользоваться, о чем как раз и идет речь.
Было бы интересно узнать поподробнее об отзывах пользователей/партнеров по поводу работы механизма с сохранением данных сессии и запросом логина/пароля. Может дело в том, что на момент появления формы запроса пароля экран с данными пропадал?
Я говорю про пользователя, ради которого собственно разработчик и делает все эти, как вы говорите "кишочки" и про отсталость старого подхода с тупым "протуханием" сессии, которое мы наблюдаем на 99% сайтов в рунете. Подход неправильный, о чем и идет речь
Исключая фокусы с AJAX, да. Но в том же ЖЖ, WordPress (да и много где) придумано решение: прозрачно для юзера сохранять данные "в черновик".
И слабо представляю, как это можно обобщить на формы любых типов, кроме как выдачей предупреждения. Текст конечно надо поправить, чтобы страшных слов не было, а просто мол, "мы вас давно не видели, здравствуйте, чего изволите-с", но это уже и кастомизировать недолго.
Олег, посоветуй как поправить текст, чтобы звучало мягче.
Но подумаю.
Я вообще не ставлю под сомнение существование сессий, кук и прочего.
Я говорю о том, что пользователю все это по барабану. Он данные потерял, о сохранности которых не подумал разработчик.
Возможно разработчик просто плохо подумал. Возможно он не думал вовсе, так как привык работать по-старому. Может быть подумал хорошо, но не было бюджета в проекте на эти работы. Поэтому просто запихнули стандартную форму и обработчик.
Дело не в этом. Не в механизме, а в решении.
К сожалению также могу констатировать, что и в моих проектах мы далеко не так часто, как хотелось бы реализовываем вот такие вот правильные методы обработки форм. И в этом безусловно новая версия главного модуля явно поможет.
Надеюсь теперь
А вы не рассматривали вариант отправки асинхронного запроса на сервер за минуту до окончания сессии?
Это совсем не сложно, но тогда безопасность и производительность провисают. Нельзя так делать просто для продления сессии.
Однако, как уже было замечено выше, ваше решение все же имеет ряд недостатков. Навскидку в голову пришел ряд предложений по усовершенствованию
1. Не думаю, что безусловное автоматическое продление сессии только на страницах с открытыми для заполнения формами существенно увеличит нагрузку на сервер. Такое решение позволит полностью исключить потерю данных при перекурах, перекусах, перепалках и т.д.)) Что касается безопасности, то тут лично я вижу только две угрозы: возможность ввода некорректных или подмененных данных в форму проходящим мимо временно-свободного компа злоумышленником и незначительное увеличение запаса времени на перехват сессии для подкованного злоумышленника. После постинга формы, перехода на другую страницу сайта (которая без формы), закрытия окна браузера автопродление сессии уже не будет действовать, то есть средняя нагрузка на веб-сервер практически не изменится.
2. Если все-таки вышеописанный шаг неприемлем для текущих норм безопасности и производительности продукта, то можно предусмотреть, например, какое-нибудь ненавязчивое окошечко с кнопкой или галочкой а-ля "Я отойду, не убивайте мою сессию", расположенное "над сайтом" в зоне видимости юзера.
3. Также, при условии, что пункт 1 неприемлем, для юзеров, переключившихся, например, на просмотр видео, можно снабдить появление сообщения звуковым сигналом и изменением иконки и/или title забытой вкладки/окна. Сохранение введенных данных в куках - как приятное дополнение. Хотя, первый пункт решает эту проблему лучше.
4. Ну, если уж не отказываться от предупреждающего сообщения, то можно предусмотреть нам нем кнопочку "Скопировать введенные данные в буфер обмена". Хотя, опять же, система черновиков, хранящихся в куках, пожалуй, поинтересней будет.
Вот как-то так
Есть ситуация, когда пользователь после длительного перерыва возвращается к странице и мы сегодня показываем ему сообщение, что сессия истекла. Он дергает страницу и сервер восстанавливает ему авторизацию, так как она была запомнена для этого пользователя на этом сервере (в соответствии с политикой безопасности группы). Т.е. на самом деле, он мог бы продолжить работу без сообщения.
Чтобы избежать этой ситуации, мы решили, что перед показом сообщения, сами незаметно дергать сервер, проверять, может ли пользователь быть повторно авторизован. Если да – система авторизует его и сообщение показано пользователю не будет.
Это фактически приведет к тому, что сообщение будет показываться пользователю уже только в том случае, когда сервер наверняка запросил бы у него логин и пароль. Т.е. 99% обычных посетителей сайта никогда не увидят нашего сообщения и будут гарантированно и уверенно работать с сайтом.
Вообще, с сессиями все очень сложно у нас устроено по соображениям безопасности. Идентификаторы постоянно меняются, сессия защищается специальным идентификатором, привязываются к IP и масса других хитростей.
Но мы нашли безопасное решение как сохранить все политики безопасности и обеспечить надежную работу Живых сессий.
1. Сообщение не будут видеть только пользователи, у которых запомнена авторизация? Просто немного смутила величина 99%
2. Если пользователю будет показано сообщение и, соответственно, он должен будет затем вручную авторизоваться, все-таки потеряются ли те данные, которые он ввел в форму до этого?
3. Процедура автоматической авторизации будет работать прозрачно для пользователя? Иными словами, пользователь будет после постинга формы видеть еще раз эту форму с данными или уже страницу с результатом?
Да, видимо погорячился
Ну если форма правильно написана, пользователь нажмет отправить, авторизуется, то да, данные примутся правильно.
Но думаю, что пользователь уже не станет посылать сообщение, скопирует большой текст и опять заполнит форму после авторизации.
Да, прозрачно. Если он не увидел сообщения, значит мы его авторизацию восстановили успешно и он все отправит на сервер правильно.
На сайте выключена установка бет. То есть "живой сесии" еще нет. В блогах используется кастом-шаблон. При загрузке картинок в окне загрузки вылезает надпись "Ваша сессия истекла, тра-ляля" -- явно без оформления, то есть в какой-то компонент или шаблон уже прокралось.
В саппорт писать ли?
перед нажатием кнопки отправить, делаю Ctrl+C формы, потом отправляю и если косяк, вставляю текст заново =)
Есть только вопрос к Сергею как будет развиваться резервное копирование в этом случае?
Есть пример, сайтик с объемом 1.3 тб, средствами битрикса сделать архив не было ни одной удачной попытки... даже убивая на нем видео, остается 530 мегов, и также попытка проваливается, точнее просто невозможно дождаться конца процедуры, пробовали ждать 9 часов, другими средствами архив делается 37 минут! В результате архив делается в два этапа сами файлики отделно и бд отдельно
----------
Предлагаю
А то на некоторых сайтах, как будто специально, все сделано против посетителей.
(в смысле даже если он безобидный на самом деле)
UPD: Оказывается, это обновление еще в бете
Сергей, а для гостей как обстоят дела? Если у него открыто окно, сессия будет поддерживаться (режим аналогичный для запомненной авторизации в случае авторизованного)?
Да, ты нас понял!
Для гостя, будет продлеваться сессия пока он как-то движется в браузере и живет. Если сессия умерла, мы не сможем восстановить старую сессию, ведь он не запоминал себя и нет надежных идентификаторов. Но мы и показывать сообщение ему не будем, мне кажется. Уточню сейчас
В модуле веб-аналитики есть ссылка "Сейчас на сайте". Кажется, ранее мы не могли знать с нами еще посетитель или уже ушел и считали по времени жизни сессии (вроде.) Раз вы все равно написали такой замечательный функционал, почему бы его не связать с веб-аналитикой, чтобы админ имел достоверную и актуальную информацию о пользователях онлайн? Эта же инфа в статистике форума выводится.
То что у вас сохраняется авторизация, к примеру, не относится к Живой сессии.
P.S. Юзаем виртуальную машину битрикса с образа на Амазоне.
У нас некоторые пользователи могут открыть портал, выполнять другую работу, а затем через час или 2 вернуться к нему и обнаружить, что сессия закрыта, пароль нужно вводить еще раз.
Можно ли где-то время жизни сессии задать не 24 мин, а, скажем, 60 мин?
Если коротко: Настройки - Пользователи - Группы пользователей -
Во вкладке 'Безопасность' для выбранной группы пользователей вводим нужное время жизни сессий.
сессия закончилась, предупреждение вылезло, но после перезагрузки страницы и авторизация сохранилась и страница на которой был осталась та же?