bitrix время жизни сессии

Постоянное разлогинивание Битрикс24

Причины и решение для пользователей коробочной версии продукта

Ситуации, когда CRM-система теряет сессию и выкидывает пользователя из портала, возникают редко. С данной проблемой мы столкнулись при работе с одним из наших новых клиентов. Он пользуется коробочной версией системы, а значит решение за собственником портала. Если подобная ошибка возникла у вас на облачной версии – обратитесь в техническую поддержку разработчика Битрикс24.

В статье расскажем о решении проблемы с разлогиниванием пользователей коробочного Битрикс24.

Разберем проблему в 3 этапа:

Симптомы проблемы разлогинивания Битрикс24

Нашим специалистам отдела инфраструктуры поступила задача: на портале клиента наблюдается плавающее время разлогинивания. Иногда 5-10 минут, иногда 20-30 секунд. Фактически после любого действия и перехода на портале пользователя выкидывало на страницу авторизации.

Проблема наблюдалась на стороне всех пользователей, вне зависимости от того, являются они администраторами или нет, и выглядела следующим образом:

Быстрое тестирование показало, что проблема наблюдается в разных браузерах и не зависит от них. Мы проверили три самых популярных браузера:

Определившись с симптомами проблемы, мы начали выяснять ее причины.

Причины разлогинивания

Причин для разлогинивания может быть несколько, расскажем о 5 часто встречающихся.

Первая причина, которую можно сразу предположить – минимальное время действия сессии.

Простыми словами, сессия – это время, в течение которого авторизованный на портале пользователь может бездействовать без необходимости повторного ввода логина и пароля. Однако сомнения вызывало чересчур короткое время разрешенных действий на портале – от 20 секунд до 15 минут. В среднем, время сессии по умолчанию равняется 24 минутам.

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

Например, CloudFlare. Если вы пользуетесь данным сервисом для защиты от DDOS-атак, то с большой долей вероятности причина кроется именно в этом.

На просторах интернета это довольно распространенная ошибка, вызывающая неудобства для пользователей. Постоянно слетающая авторизация не позволяет править элементы и совершать банальные действия на портале.

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

Третья причина может быть скрыта в смене провайдера.

При переносе коробочной версии портала на другой хостинг могут возникнуть проблемы с правами доступа к файлам и каталогам.

Четвертая причина – проблема с обновлениями или конфигурационными файлами системы.

«Сломать» Битрикс24 через административную панель пользователю, не обладающему достаточными компетенциями, очень просто. Достаточно лишнего пробела или одной удаленной строчки из конфигурационного или любого другого системного файла для того, чтобы нарушить работу портала.

Пятая причина – права доступа.

Файлы dbconn.php, init.php и after_connect.php с сессиями продукта создаются, но PHP не хватает прав доступа, чтобы к ним обратиться.

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

Решение проблемы

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

Первый шаг – настраиваем время сессии. Существуют разные способы определения и установки времени жизни сессии. Рассмотрим три из них:

1. Настройка сессии на веб-сервере:

Выполняется путем редактирования файла php.ini. Данный способ подходит для администратора веб-сервера.

В файле php.ini нужно исправить следующие строки:

session.gc_maxlifetime = 172800
session.cookie_lifetime = 0

Параметр gc_maxlifetime — время в секундах, по истечению которого данные могут быть удалены. 86400 — 48 часов (2 суток) в секундах. Если установить значение 0, то время действия сессии будет бесконечным. Однако это может привести к падению производительности и безопасности сервера.

Параметр cookie_lifetime — время жизни файлов cookies.

2. Настройка сессии в файле .htaccess

Файл .htaccess позволяет системному администратору управлять настройками веб-сервера. Для редактирования .htaccess требуется доступ к файлам сайта, которые, как правило, хранятся на сервере. Данный способ не сработает, если в качестве обработчика PHP используется не Apache. В противном случае понадобятся более глубокие настройки веб-сервера.

В файл .htaccess следует вписать:

php_value session.gc_maxlifetime 172800
php_value session.cookie_lifetime 0

Данный способ практически аналогичен первому (настройке через php.ini.).

3. Настройка времени сессии в административной панели – самый простой способ для пользователя с административными правами на портале Битрикс24, не желающего напрямую работать с файлами сервера.

Для установки времени сессии нужно зайти в панель Администрирования и перейти в панель Настройки. Далее нужно зайти в Группы пользователей и для нужных групп в разделе Безопасность установить нужное время сессии. По умолчанию установлен параметр Не переопределять – это означает, что по умолчанию значение длительности сессии берется из настроек сервера.

Настроили время сессии, движемся дальше.

Второй шаг – определить хостинг-провайдера вашего портала и внести правки на стороне используемого ресурса. Если вы не знаете, какой провайдер предоставляет вам свои услуги, можно провести диагностику на сторонних сервисах:

Если ваш хостинг-провайдер CloudFlare, то внезапное разлогинивание объяснимо – сессия обрывается инструментами защиты Битрикс24.

Для исправления ошибки необходимо внести правки в файл dbconn.php вашего сайта. Данный файл находится в папке php_interface по следующему пути:

Административная панель → Контент → Структура сайта → Файлы и папки → Bitrix → php_interface

Нажимаем на Редактировать как PHP и добавляем следующую строчку:

Вставлять ее нужно до знака ?>, иначе ничего не сработает.

P.S. в сеансах Bitrix CMS привязаны к одному IP-адресу, поэтому, если ваш IP-адрес меняется – автоматически вы больше не можете войти в систему.

Третий шаг – проверка прав доступа записи в папке хранения сессии пользователей. В случае чего, откорректировать их.

Четвертый шаг – проверить следующие системные файлы на наличие лишних пробелов или символов:

Данные файлы находятся в папке php_interface по аналогичному со вторым шагом пути:

Административная панель → Контент → Структура сайта → Файлы и папки → Bitrix → php_interface

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

Пятый шаг – предоставить права доступа PHP. Для этого нужно внести правки в файл dbconn.php, находящийся по адресу:

Административная панель → Контент → Структура сайта → Файлы и папки → Bitrix → php_interface

Выбираем Редактировать как PHP и закомментируем (ставим //) следующую строчку:

В нашем случае решающим оказался второй шаг – клиент, у которого обнаружилась проблема, пользовался услугами CloudFlare. Стоит отметить, что команда Битрикс24 также не рекомендует использовать проксирование от CloudFlare:

Мы поправили настройки, не затрагивая системные файлы, хранящиеся на хостинге. Последующие проверки ошибок не выявили. Сотрудники компании продолжили работу на портале, не отвлекаясь на ежеминутный ввод логина и пароля.

Если вы столкнулись с подобной ошибкой и не знаете, как с ней справиться, свяжитесь с нами бесплатно по телефону
+7 (495) 118-39-18 или через форму ниже. У нас есть опыт в решении частных и типовых проблем по Битрикс24.

Источник

Bitrix время жизни сессии

Современные сайты наполняются содержанием с помощью специального программного обеспечения: CMS.

Для кого этот курс?

Курс Контент-менеджер адресован тем, кто работает с содержанием сайта: наполнение, изменение текста, загрузка и размещение картинок и так далее.

У нас часто спрашивают, сколько нужно заплатить

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

уроке.

Практика и тесты

При изучении курса рекомендуется повторять описываемые действия на демонстрационной версии сайта, установленной локально или в Виртуальной лаборатории.

После изучения курса пройдите тесты на сертификацию. При успешной сдаче последовательности тестов со страницы Моё обучение скачайте сертификат об успешном прохождении курса в формате PDF.

Для преподавания оффлайн

Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 2 дня (16 академических часов).

Если нет интернета

Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

Как проходить учебный курс?

Источник

Я ненавижу, когда истекает моя сессия и теряются данные! Живая сессия?

Вам приходилось отправлять что-то в форму на сайте и получать сообщение «Ваша сессия истекла»?

Мы быстро учимся на болезненном опыте и большинство уже выработали правило, что любые большие сообщения копируют в буфер, прежде чем нажать кнопку формы.

И не думайте, что я говорю сейчас про продукты 1С-Битрикс, это свойственно всем веб-приложениям.

Что такое сессия и зачем вообще эту гадость придумали?

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

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

Вот тут как раз и возникает проблема у разработчиков. Как определить, что сессия пользователя завершена?

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

Пользователи возмущаются. Почему вообще нельзя сделать сессию бесконечно, если вы, веб-разработчик, не можете без нее делать веб-сайты?!

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

Но если вас это улыбнет, большинство веб-разработчиков даже не знают, как работают сессии, и что они используют сессионные куки и как они передаются Я не шучу. Многие веб-разработчики начали учиться программировать сайты, когда сессии уже были придуманы, и воспринимают это как данность. А ведь когда-то мы в php3 их сами эмулировали Даже сейчас завальный вопрос для начинающих сайтостроителей «Как работает сессия, нарисуйте сеанс?»

В общем сегодня сформировалась практика в сообществе, что сессия пользователя длится 20-30 минут. Т.е. если вы открыли страницу сайта и 30 минут не переходили на другие страницы сайта и не получали новые страницы в этой сессии – веб-сервер просто решит, что вы ушли и завершит вашу сессию даже не задумываясь, пишите вы пост в блог или вернулись с перекура и заполняете важную форму.

Что же делать, я ненавижу когда истекает моя сессия?!

Неоднократно я видел попытки решить эту проблему.

Обычно делают обработку форм так, чтобы даже если сессия истекла, пользователь мог ввести логин и пароль и данные в форму поступили бы в полном объеме. Мы рассуждали так же и делали такие обработки в форумах, блогах и других формах. Но как метод это себя зарекомендовало не очень хорошо. И мы не все могли уследить и, что самое главное, наши партнеры вообще об этом не успевают задуматься. Да и даже если все сделано хорошо по этой методике, пользователь видит первое сообщение, что сессия истекла и уже хватается за сердце и гневается на вас.

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

Недавний пример – Альфа-Клик. Банковский сервис крайне нуждается в соблюдении безопасности работы пользователя. Когда сессия близится к завершению, появляется такое сообщение.

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

Недавно мы решили найти системное решение этой проблемы, чтобы все сайты на нашей платформе стали более удобными для посетителей.

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

В браузере пользователя мы незаметно для него начинаем обратный отсчет. За несколько минут до завершения сессии мы включаем голову и смотрим, жив он или нет. Проверяем, когда были последние нажатия на клавиатуру, клики и движения мышки и … мы незаметно для пользователя продлеваем сессию если он еще жив. Т.е. мы шлем запрос к веб-серверу, чтобы сервер ЗНАЛ, что этот посетитель еще с нами. Сессия продлевается на сервере и никаких сообщений пользователям не показывается.

Если вы не проявляли признаки жизни больше длительности сессии, не двигали мышкой в окне браузера, не пишете текст, не кликали или не нажимали сенсорный экран, в общем, если вы забыли про эту страницу – мы покажем вам такое вот сообщение.

Это сообщение покажется как в административном разделе, так и на публичных страницах сайта.

Цель этого сообщения – просто проинформировать посетителя о том, что его сессия работы с сайтом завершена. Конечно, мы не будем показывать сообщение, если вы ходили по сайту, но не авторизовались. Если пользователь при авторизации отметил «запомнить меня», он так же сможет восстановить сессию. В общем, все будет работать как и ранее.

И, конечно, вы можете управлять живой сессией в настройках главного модуля.

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

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

Сейчас реализацией мы очень довольны надеюсь и вам она понравится.

Доступно решение будет начиная с версии главного модуля 9.5.7, который пока доступен в режиме бета-тестирования. Немного погоняем и выпустим всем для работы.

Живая сессия сделает нас добрее незаметно для нас

Источник

Время сессии

еще нашел по этой теме.

Пропадает авторизация пользователя :
Возможны разные причины проблемы:
1. Лишние переносы строк (или иные символы) в скриптах конфигурации. Убедитесь, что файлы dbconn.php, init.php и after_connect.php папки bitrix/php_interface не содержат переносов строк перед » «.
2. Файлы с сессиями продукта создаются, то PHP не хватает прав, чтобы к ним обратиться. Попробуйте в файле /bitrix/php_interface/dbconn.php закоментировать строку:
//@umask(

dbconn.php after_connect.php все нормально, одна сплошная строка, или надо не блокнотом смотреть?
init.php не содержится в папке bitrix/php_interface этого файла несколько: bitrix\components\bitrix\intranet.tasks, bitrix\components\bitrix\intranet.tasks\lang\ru, modules\intranet\install\components\bitrix\intranet.tasks,modules\intranet\install\components\bitrix\intranet.tasks\lang\ru
2. попробую если другое не поможет.
3. Вот что стоит у меня
; After this number of seconds, stored data will be seen as ‘garbage’ and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
я так понял чере 24 минуты оно уходит в garbage?)) может стоит только этот параметр исправить, повлияет ли на производительность всего сервера, не начнет ли он в пхп кроме авторизации все подряд валить?
4. у нас айпи очень редко меняются сервером dhcp, раз в месяц.
5. вот что у меня стоит:
; The domain for which the cookie is valid.
session.cookie_domain =

вот настройки сессий из пхп

на данный момент планирую побаловаться с параметрами:
session.cookie_domain =
session.gc_maxlifetime =

Источник

Настройка времени сессий в PHP

Существуют разные способы установки времени жизни сессий. Попробуем разобраться на примере операционной системы Linux.

Как узнать время жизни сессии

Перед настройкой, стоит посмотреть текущее состояние. Есть несколько методов это сделать:

1. На сервере командой php

Получаем список параметров, имеющих отношение к сессиям. Нас интересуют:

Данные значения — значение по умолчанию. cookie_lifetime => 0 говорит о действии файлов куки до закрытия браузера, если задать этому параметру определенное значение, сессия будет прерываться при активном сеансе, поэтому лучше ее оставлять в значении ноль.

2. C помощью php-функции ini_get

Настройка сессий на веб-сервере

Выполняется путем настройки файла php.ini. Данный способ удобен, если мы являемся администратором веб-сервера, а также если есть гарантия, что общая настройка сессий не повлияет на работоспособность всех веб-приложений, работающих на данном сервере.

Открываем на редактирование php.ini. Его расположение зависит от сборки Linux. Точный путь можно посмотреть командой:

Теперь открываем сам файл:

В некоторых системах, например, Ubuntu или Debian для каждой среды обработки кода создается свой php.ini файл, а также для каждой версии PHP. Например, по пути /etc/php/7.4/fpm/php.ini находится файл для php-fpm для PHP версии 7.4. Нам необходимо учитывать данный факт, чтобы настроить нужный файл.

И редактируем следующие параметры:

session.gc_maxlifetime = 86400
session.cookie_lifetime = 0

* где параметр gc_maxlifetime указывает на временя в секундах, после прошествии которого данные могут быть удалены; cookie_lifetime — время жизни файлов cookies; 86400 — 24 часа в секундах.
* если параметру gc_maxlifetime задать значение 0, действие сессий будет бесконечным. Это, как правило, не стоит делать — приведет к падению производительности и безопасности сервера.

После настройки параметров, необходимо перезагрузить сервер, являющийся интерпретатором PHP.

systemctl restart apache2 || systemctl restart httpd

* в версиях Linux без systemd используем команду service apache2 restart или service httpd restart.

Если используем FastCGI (PHP-FPM).

systemctl restart php-fpm

б) для Ubuntu или Debian:

systemctl restart php7.4-fpm

* где 7.4 — версия используемого PHP.

Данный файл позволяет веб-мастеру управлять некоторыми настройками веб-сервера. Для его редактирования нужен доступ к файлам сайта. Способ не сработает, если в качестве обработчика PHP используется не Apache, а, например, NGINX + PHP-FPM. Хотя, тут тоже есть способ (о нем будет ниже).

php_value session.gc_maxlifetime 86400
php_value session.cookie_lifetime 0

* как можно заметить, параметры те же, что при настройки через php.ini.

Как говорилось выше, метод не сработает, если не используется Apache. Однако настройку можно выполнить на сервере (опять же, у нас должен быть соответствующий доступ).

Открываем файл настройки веб-сервера, например, в php-fpm:

php_value[session.gc_maxlifetime] = 86400
php_value[session.cookie_lifetime] = 0

После перезапускаем сервис:

systemctl restart php-fpm || service php-fpm restart

Задание параметра в коде приложения

Способ может быть полезен, когда разные страницы портала должны иметь разное время жизни сессии. Для этого можно воспользоваться PHP-функциями ini_set и session_set_cookie_params, например:

Функции обязательно вызывать до открытия сесии (session_start).

Установка сессии в приложении

Некоторые приложения могут переопределять настройки. В таком случае, задать время жизни сессии необходимо в параметрах программы. У каждого приложения свои настройки, в которых необходимо самостоятельно разобраться. Приведем для примера настройку сессии в CMS Битрикс.

Как автоматически продлевать сессии

Если сессия выдается на определенный период и заканчивается в определенное время, это может привести к прерыванию активного сеанса пользователя. Гораздо удобнее, если время действия сессии будет автоматически продлеваться, если посетитель обновляет страницу. Для этого существует параметр cookie_lifetime, который во всех примерах выше мы задавали в значении 0.

Если мы зададим значение cookie_lifetime 86400, то через 24 часа сессия прервется. Это не всегда удобно.

Если есть необходимость в контроле и прерывании сессии, можно воспользоваться php-функцией session_destroy().

Путь хранения файлов сессий

Место хранения файлов сессий задается параметром session.save_path также, так время жизни. По умолчанию, может использоваться путь /var/lib/php/sessions.

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

Источник