Меню

Bitrix сохранение сессии ошибка не работает

В новой записи я расскажу как я решил проблему с сохранением параметров сессии на Bitrix. Сайт располагался на VPS под Ubuntu (хостинг beget).

Авторизуемся на сервере и узнаём версию PHP через команду в консоли

Вам нужно авторизоваться под пользователем root. После авторизации в консоли пишем команду

php -v

Находим пути до файла с конфигурацией PHP на сервере (php.ini)

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

find / -name "php.ini"

Создаём директорию для файлов сессий

Для файлов сессии я создал директории по следующему пути /home/user/tmp/sessions

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

user может быть заменён на имя вашего пользователя.

Изменяем конфигурацию в файле php.ini для сайта Bitrix

Прописываем в значение параметра для session.save_path=/home/user/tmp/sessions

И строкой нижу пропишем — extension=session.so

Добрый день.
Сайт на битриксе, дебиан, nginx+phpfpm, bitrix vm не используется. Домен сейчас делигирован на яндекс, производим делегирование домена в другое место. И появилась проблема По старому адресу сессии работают нормально, при переключении на новый адрес сессии не сохраняются.

При попытке изменить тот же заказ получаю такую ошибку:

Ошибка обработки запроса. Наиболее вероятные причины: у пользователя недостаточно прав; проблемы с сохранением сессий PHP; часть данных POST-запроса обрезается PHP либо веб-сервером.

Что с этим делать не понятно. Специалистов по серверам у нас нет.
Техподдержка куда переводим делегирование на это дала такой ответ:

Вероятно при генерации куки всё же используется IP-адрес пользователя.
Ранее IP-адрес пользователя и IP-адрес устанавливающий соединение совпадали и IP-адрес пользователя вероятно брался из переменной remote_addr.
Сейчас IP-адрес пользователя и IP-адрес, с которого приходит запрос, не совпадают из-за того что запросы проходят через наши проксирующие сервера. IP-адрес может меняться и это вероятно вызывает затруднения с сессиями.
С вашей стороны необходимо или изменить передачу IP-адреса пользователя в битрикс (мы передаем IP-адрес пользователя в заголовке X-Real-IP) или не учитывать его в куки.

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

Столкнулся с проблемой: в битрикс не работают сессии. Функция bitrix_sessid() каждый раз выдает новую строку. В админке авторизация работает, но никакой ajax функционал — нет. Везде ошибка что сессия не верная, при этом проблема плавающая. То ошибка есть, то само по себе начинает работать.

Проблема оказалась просто в том, что на сервере закончилось свободное место на диске.

Чтобы долго не сидеть и не гадать в чем у вас проблема, выкладываю скрипт. Сохраните его в корень сайта, например с именем test.php и запустите из браузера:

<?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);

if (! session_start()) {
    die('can not start session');
} else {
    echo '<pre>session start: ok' . PHP_EOL;
}

echo 'session_id(): ';
var_dump(session_id());

echo '$_COOKIE["PHPSESSID"]: ';
var_dump($_COOKIE['PHPSESSID']);

echo 'count($_SESSION): ';
var_dump(count($_SESSION));

echo '$_SESSION["a"]: ';
var_dump($_SESSION["a"]);

echo '$_SESSION["a"] = 1';
$_SESSION["a"] = 1;

Сессия должна стартовать, в session_id() должна быть какая-то строка, та же что и в $_COOKIE[‘PHPSESSID’]. При перезагрузке страницы id сессии не должно меняться.

После второй перезагрузки страницы $_SESSION[«a»] должно быть установлено в 1.

Вывод ошибок включен, если что — PHP напишет что не так. Я получил ошибку No space left on device (28), что говорит о том, что не хватает места на сервере.

Пожалуйста, оцените на сколько вам понравилась статья!

Итак, имеем чистую установленную CentOS 6

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

# yum update
# yum install epel-release
# yum install mc bash-completion wget

Создаем пользователя с полными правами:

# useradd -m myadmin
# passwd myadmin
# vi /etc/sudoers

и добавляем строку чтобы получилось

root ALL=(ALL) ALL
myadmin ALL=(ALL) ALL

Для CentOS 6 есть удобная штука Bitrix Enviroment — скрипт, который разворачивает весь набор ПО для Битрикса.

# cd /root
# mkdir bitrix
# cd bitrix
# wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh
# chmod +x bitrix-env.sh
# ./bitrix-env.sh

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

У Bitrix Enviroment есть одно неудобство: все настроено для работы с 1 сайтом, а если на сервере необходимо развернуть несколько инсталляций Битрикса и иных CMS — необходимо поработать руками.

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

Ставим:

# yum install mod_ruid2

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

# cp /etc/httpd/conf.d/mod_ruid2.conf /etc/httpd/bx/conf/

В настройках виртуального хоста добавить строчку:

<VirtualHost 127.0.0.1:8888>
...
RUidGid myuser mygroup
...

В файле mod_ruid2.conf можно найти полное описание директив и настроек.

Перезапускаем httpd, проверяем все ли работает — для этого создаем файл ruid2.php и открываем его в браузере

<?php
print `id`;
?>

Должна открыться страничка с примерно такимответом:

uid=1002(myuser) gid=1000(mygroup) groups=1000(mygroup),33(bitrix)

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

Предупреждение

Apache mpm-itk значительно медленнее prefork и event, поэтому на высокую оценку Битрикса рассчитывать не стоит (в меню Настройки → Производительность → Панель производительности плохие показатели будут в подсистемах «Среднее время отклика», «Файловая система» и как следствие «Конфигурация»). Лучше использовать вышеописанный mod_ruid2

# yum install httpd-itk.x86_64 

Запускаем Apache в режиме mpm-itk: добавляем в /etc/sysconfig/httpd строку

HTTPD=/usr/sbin/httpd.itk

Правим настройки PHP: добавляем в файлы /etc/httpd/bx/conf/php.conf и /etc/httpd/conf.d/php.conf строки

<IfModule itk.c>
  LoadModule php5_module modules/libphp5.so
</IfModule>

Добавляем в файл /etc/httpd/conf/httpd.conf строки (кол-во запускаемых серверов и обслуживаемых клиентов зависит от конкретного сервера, необходимо подбирать самостоятельно):

<IfModule itk.c>
StartServers 1
MinSpareServers 1
MaxSpareServers 20
ServerLimit 50
MaxClients 100
MaxRequestsPerChild 4000
</IfModule>

В файле /etc/httpd/conf/httpd.conf заменяем строку

ServerTokens OS

на

ServerTokens Prod

Необходимо удостовериться что у пользователя под которым работает nginx есть права на чтение папок www

В файле /etc/nginx/nginx.conf настраиваем:

Корректируем число процессов под свою систему:

worker_processes 2;

Скрываем версию:

server_tokens off;

Fatal error: Call to undefined function mysqli_init() in /home/MYSITE/www/bitrix/modules/main/lib/db/mysqliconnection.php on line 48

Необходимо включить расширение PHP для работы с MySQL — оно называется mysqli. Опять же — если его включить ДО восстановления сайта из резервной копии то на третьем шагу восстановления (а именно базы данных) — получим симпатишный белый экран.

# cd /etc/php.d
# mv 30-mysql.ini 30-mysql.ini.disabled
# cp 30-mysqli.ini.disabled 30-mysqli.ini
# service httpd restart

Альтернативный вариант заключается в отключении использования mysqli Битриксом: в файле bitrix/php_interface/dbconn.php исправляем строку

define("BX_USE_MYSQLI", true);

на

define("BX_USE_MYSQLI", false);

И в файле bitrix/.settings.php поменять

'className' => '\Bitrix\Main\DB\MysqliConnection'

на

'className' => '\Bitrix\Main\DB\MysqlConnection'

чтобы получилось

....
'connections' => 
array (
  'value' => 
  array (
    'default' => 
    array (
      'className' => '\Bitrix\Main\DB\MysqlConnection',
....

Добавляем в /etc/hosts запись

127.0.0.1 mydomain.ru

В файле /etc/php.d/bitrixenv.ini меняем

pcre.recursion_limit = 14000

на

pcre.recursion_limit = 100000

В скрипте запуска сервера HTTP Apache /etc/rc.d/init.d/httpd изменить функцию «start()», добавив в нее одну строку (ulimit -s unlimited):

start() {
echo -n $"Starting $prog: "
ulimit -s unlimited
LANG=$HTTPD_LANG daemon --pidfile=${pidfile} $httpd $OPTIONS
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch ${lockfile}
return $RETVAL
}

и перезапускаем httpd

# service httpd restart

Решение для CentOS 7

Отсюда: http://host-consult.ru/pcre-recursion_limit-bitrix-centos7/

Создаем папку для дополнительного конфигурационного файла сервиса httpd:

# mkdir /etc/systemd/system/httpd.service.d

Внутри создаем файл, например recursion_limit.conf и в него пишем:

[Service]
LimitSTACK=infinity

Перегружаем демона и сервис:

# systemctl daemon-reload
# systemctl restart httpd

Существенное замечание

Снять ограничение на лимит стека, это рекомендация Битрикс. Скажем прямо не самая удачная, т.к. вы можете решив одну проблему заполучить проблему с постоянной нехваткой ОЗУ. И apache будет падать уже по этой причине. Поэтому лучше подобрать верхнее граничное решение, которое будет устраивать Битрикс. Вычислить его достаточно просто:

Обычно кэш равен 8 Мбайт, убедимся:

# ulimit -s
8192

Соответственно, нам нужно немного больше, пусть это будет 9 Мбайт: 1024*1024*9 = 9 437 184 байт

пишем в наш файл:

[Service]
LimitSTACK=9437184

В файле /etc/php.d/bitrixenv.ini меняем

sendmail_path = msmtp -t -i

на

sendmail_path = sendmail -t -i

В файле /etc/php.d/bitrixenv.ini меняем

date.timezone = Europe/Moscow

на свою, например

date.timezone = Asia/Krasnoyarsk

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

Хост не может разыменовать свое доменное имя

Добавляем в файл /etc/hosts строку

127.0.0.1  mydomain.ru

Веб-сервер не может сохранить файлы сессии

Путь в файловой системе куда сохраняются сессии прописан в файле /etc/php.d/bitrixenv.ini и по умолчанию там прописано следующее значение:

session.save_path = "/tmp/php_sessions/www"

Таким образом нужно удостовериться что данная папка существует, внутри нее так же есть еще две папки: www и www_ext и права установлены следующим образом:

# cd /tmp
# ls -l
drwxrwx---  4 bitrix bitrix 4096 Sep 14 13:44 php_sessions
# cd php_sessions
# ls -l
drwxrwx--- 2 bitrix bitrix 4096 Sep 14 13:44 ext_www
drwxrwx--- 2 bitrix bitrix 4096 Sep 14 13:45 www
firewall-cmd --zone=public --add-port=25/tcp   --permanent
firewall-cmd --zone=public --add-port=80/tcp   --permanent
firewall-cmd --zone=public --add-port=443/tcp  --permanent
firewall-cmd --zone=public --add-port=5222/tcp --permanent
firewall-cmd --zone=public --add-port=5223/tcp --permanent
firewall-cmd --zone=public --add-port=8890/tcp --permanent
firewall-cmd --zone=public --add-port=8891/tcp --permanent
firewall-cmd --zone=public --add-port=8893/tcp --permanent
firewall-cmd --zone=public --add-port=8894/tcp --permanent
firewall-cmd --reload

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

bitrix_server_test

Одним из таких сообщений является «Сохранение сессий без UserAgent». Вроде бы понятно, но в то же время не ясно куда смотреть. В конце концов, немного поискав на форумах, и не найдя ничего конкретного решил залезть в сам скрипт. Отыскав строку (примерно на линии 622), где происходит эта ключевая ошибка, нашел такую запись, которая собственно и подсказала точную причину ошибки.

$res = fsockopen(($port == 443 ? 'ssl://' : '').$host, $port, $errno, $errstr, 3);

Проблема была в том, что у функции fsockopen не удавалось подключиться к хосту, а само сообщение об ошибке помещалось в переменную $errstr. В переменной $errstr было следующее:

php_network_getaddresses: getaddrinfo failed: Name or service not known

Иными словами, не удалось получить имя хоста. Проблему удалось решить довольно просто, т.к. сервер поднимался на виртуальной машине под CentOS, то в конфигурационном файле /etc/host было достаточно прописать доменное имя сайта.

Открываем файл /etc/hosts:

vi /etc/hosts

Добавляем строку:

127.0.0.1 mydomen.loc

где mydomen.loc – доменное имя вашего сайта.

Описаны некоторые проблемы и способы их решения.

  1. Бизнес-чат в реальном времени – Функция работает частично неправильно, желательно устранить ошибки.
    Для её решения достаточно посмотреть журнал проверки, в котором всё подробно описано. Настройки продукта-Настройки модуля-выбрать Главный модуль, раздел авторизация, убрать галки Продлевать сессию при активности посетителя в окне браузера и Продлевать сессию только для авторизованных посетителей.
  2. Сохранение сессии без UserAgent.
    Веб-сервер не может сохранить файлы сессии. Путь в файловой системе, куда сохраняются сессии, прописан в файле /etc/php.d/bitrixenv.ini и по умолчанию там указано следующее значение: session.save_path = “/tmp/php_sessions/www”. Таким образом, нужно удостовериться, что данная папка существует. Самым оптимальным способом будет вызвать функцию phpinfo() и проверить значение “session.save_path”, т.к. его могут перезаписать значения в .htaccess или что-то ещё. Владельцем директории под сессии с правами 0755 должен быть пользователь bitrix (или тот, от которого работает веб-сервер).
  3. Интеграция с соцсетями, замечание:
    В модуле социальные сервисы поставить галочку напротив Битрикс24.

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Bitrix ошибка при загрузке файла
  • Binkw64 dll skyrim se ошибка