Файл обработчик в публичной части сайта не найден необходимо наличие pub imbot php

Обновлено: 04.07.2024

Теперь разъяснения этого кода. Думаю на счет таких тегов как <title> , <body> , <head> и так все понятно, так что перейдем сразу к форме.

Здесь мы пишем тег <form action="forma.php" method="POST"> , который указывает, что форма будет обрабатываться скриптом forma.php и передаваться данные будут методом POST (что такое POST и GET). Дальше мы создаем поле ввода текста и даем ей имя myname вот этой строкой:

Затем создаем кнопку, при нажатии на которую, данные из формы будут переданы скрипту forma.php .

Теперь перейдем к скрипту обработчику forma.php . Здесь такой код:

– здесь хранится информация, которую мы ввели на странице html в поле ввода текста с именем myname .

Дополнение (другими словами):

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

Вывод пустой формы или заполненной
Отсылка заполненной
Если не прошли валидацию, то выводим форму с уже введёнными данными и показываем где ошибка, форма не должна разваливаться из-за текста («>tets)
Если всё верно — сохраняем данные, при необходимости обрабатывая, дабы не было инъекций и прочей гадости при выводе данных
Делаем редирект, дабы на f5 данные не посылались заново.

Набросаем класс формы. Он должен уметь:

Работать в своём нэймспэйсе, пространстве имён, чтобы на одной странице можно было разместить несколько форм. Например блок логина и контактную форму. Для этого будем передавать в конструктор имя, а название полей будут в виде массива имя_формы[имя_поля]
Заполнять поле значением по умолчанию или брать значения из переменной $_POST[имя_формы][имя_поля] . Для ручной установки значения используем хак и будем это значение совать в суперглобальную переменную $_POST. Это не совсем хорошо, но очень удобно. Получаем методы getValue и setValue .
Проверка данных. Для этого будут методы setInvalid в который передаются имя поля и текст ошибки, isInvalid для проверки прошли ли проверку (с именем — для конкретного поля, без имени для всей формы).
Ну и последние, но очень важные функции для проверки страница открыта просто по ссылке или же была отправлена форма — метод isPost. А для проверки какая форма была отправлена будет метод isSubmit, который проверяет наличие нашего нэмспэйса в $_POST .

Вот что у меня получилось:

Теперь необходимо соорудить непосредственно обработчик:

Сперва отправили заголовок, чтобы не было проблем с кодировкой, затем подключили класс. Внимание это делается с помощью require_once , постфикс _once говорит, что подключаем файл только один раз, а require гарантирует, что в случае ошибки код не продолжится выполняться и не вылезет ещё десяток ошибок, как при include. Далее создали объект формы с именем form, проверили была ли отправлена данная форма. Если нет, то устанавливаем значение по умолчанию и выводим шаблон формы (include, так как не влечёт за собой других ошибок).

Если же форма была отправлена, то делаем проверку на заполнение поля, выставляем текст ошибки. если же не было ошибок !$form->isInvalid() , то сохраняем или что там и редиректим на thank.php .

Теперь рассмотрим сам шаблон

и удалить весь код внутри этого сайта, затем обновите страницу и ошибка Forbidden исчезнет. Но это еще не все.
Если вы вернете код на место, либо обновите битрикс, то будет все тоже самое, вы не смоете попасть в административный раздел вашего сайта.
Вам нужно зайти в Настройки->Проактивная защита->Защита административного раздела и отключить защиту по IP, либо прописать там ваш текущий IP.

Затем можете смело возвращать на место удаленный код в файле security_403.php ведь менять и тем более что-то удалять в файлах ядра битрикс категорически запрещено.
Как такое случилось?
Просто у вас сменился IP адрес. Вы или ваш провайдер сменили его, возможно вы поменяли провайдер или подключились к интернету через телефон, прокси, VPN и тд.
блин оказывается кто-то IP вёл а я голову ломал, спасибо помогли

24.окт.2021 Битрикс Работа с сокетами Ошибка! Не работает
В проверке сайте можно наблюдать такую ошибку
Работа .

17.июл.2021 Как передать Roistat в заказ 1С-Битрикс
Передать ID Roistat можно в сам заказ в Битриксе после его о.

21.июн.2021 Сбой на файле, ошибка распаковки пакета
При очередном обновлении 1С-Битрикс выскочила ошибка [UUGZA0.

03.июн.2020 Не выводиться заглушка в композитном кеше
Столкнулся с тем, что при указании заглушки в динамической о.

01.апр.2020 Установка SSL сертификата LetsEncrypt на BitrixVM
Установка SSL сертификата LetsEncrypt на виртуальную машину .

07.мар.2020 Битрикс настройка SSL, ошибка работы с сокетами
Заходим в меню битрикса выбираем 8. Manage pool web servers .

14.ноя.2019 Не выгружаются заказы в 1С
Не выгружаться заказы в 1С из сайта на битрисе могут по разн.

07.ноя.2019 Видео youtube на фон сайта
Как-то на сайт мне нужно было вывести видео на весь экран, к.

05.ноя.2019 Свойство с большим списком (датой)
Если в инфоблоке необходимо использовать свойство типа списо.

05.ноя.2019 Основные настройки BitrixVM
Приведу основные пути и файлы конфигурации в виртуальной маш.

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

PHP как CGI (не путать с FastCGI). В этом случае на каждый хит запускается собственный процесс, который делает какую-то обработку, а потом гасится. Ресурсоёмкая и долгая операция, проект при такой настройке будет работать непроизводительно.
Использование параметра open_basedir в PHP, который призван изолировать клиентов на сервере друг от друга. Этот параметр не панацея в плане безопасности, и существенно снижает производительность.
Не установлен прекомпилятор PHP на хостинге. Часто его нужно включать самостоятельно. Прекомпилятор интерпретирует php скрипт в байткод, обрабатывается и сохраняет в кеше. В последующем интерпретация не требуется, байткод получается из кеша. Прекомпилятор снижает нагрузку на процессор и ускоряет исполнение php скриптов.
Недостаточно памяти прекомпилятору, в результате кеш для прекомпилированных скриптов будет работать крайне неэффективно на больших проектах.
Медленная файловая система и/или мало дискового кэша.
Отсутствует FrontEnd (NGINX). Подробнее смотрите в курсе для хостеров
NGINX есть, но всю статику запрашивает у Apache.
Не отрегулировано значение MaxClients в Apache.

Прекомпиляторы

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

Можно ли без Apache? PHP-FPM

Возможно использование вместо Apache модуля PHP-FPM. Этот вариант обладает с одной стороны неудобством: если у вас много логики, завязанной на файл .htaccess , то эту логику надо перенести отдельно в конфиг NGINX. Это делается один раз, но потом останутся только удобства.

Apache при каких-то ошибках не умеет сам себя рестартовать, нужны внешние обработчики. А на больших нагрузках достаточно часто могут возникать ошибки вида segmentation fault. PHP-FPM может делать рестарт внутренними средствами:

; рестартовать при ошибках emergency_restart_threshold = 1 emergency_restart_interval = 10

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

pm = ic pm.max_children = 30 pm.start_servers = 30 pm.min_spare_servers = 30 pm.max_spare_servers = 30

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

PHP-FPM очень хорошо подходит для ограничения прав доступа, если на одном сервере работает несколько проектов. В этом случае для каждого проекта можно выделить свой пул, выделить свой chroot. В отличие от open_basedir он никаким образом не снижает производительность, успешно разделяя пользователей.

; не open_basedir в php.ini chroot = /var/www/chroot

Более того, можно задать разные пулы, разные конфигурации под разные сервера.

Чек-лист по настройке

Примерный чек-лист, который должен быть выполнен при настройке веб-сервера:

Коробка: настройки сервера и модуля портала

Для работы открытых линий в «Битрикс24 в коробке» необходимо сделать предварительные настройки сервера и модуля портала.

Внимание! Данные настройки должен выполнять Администратор системы.

Общие серверные настройки

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

Должен быть действующий лицензионный ключ.

Параметр Nginx: nginx proxy__client_abort on необходимо включать для конкретного location.

Если используется php-fpm, вместо nginx proxy__client_abort on нужно использовать параметр fastcgi__client_abort on.

Для работы коннектора Онлайн-чат: для location /online/(/?)([^/]*) разрешить X-Frame-Options SAMEORIGIN (открывать эту страницу как фрейм из любого сайта или только того, где будет расположен фрейм). Такие настройки могут быть в Nginx и в модуле Проактивная защита в разделе Защита от фреймов (Настройки > Проактивная защита > Защита от фреймов);

Для работы коннектора Битрикс24.Нетворк:

Примечание: В некоторых случаях может потребоваться отключить редиректы для файла коннектора вида

Настройка модуля Коннекторы для внешних мессенджеров

Настройка модуля Коннекторы для внешних мессенджеров (Настройки > Настройки продукта > Настройки модулей > Коннекторы для внешних мессенджеров) проста:

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

Настройка модуля Открытые линии

Для ведения лога ошибок самого модуля Открытые линии (Настройки > Настройки продукта >Настройки модулей > Открытые линии) можно также включить Режим отладки:

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

Так отображаются экстранет-пользователи в списке пользователей

Настройка модуля Чат-боты Битрикс24

Настройки модуля Чат-боты Битрикс24 (Настройки > Настройки продукта >Настройки модулей > Чат-боты Битрикс24) также особой сложности не вызывают:

Примечание: Подробнее про чат-бот Поддержка Битрикс24 в коробке можно прочитать в одноименной статье.

Переезд на кластер под управлением «1С-Битрикс: Веб-окружение»

Собственно, если мы обратимся на сайт вендора, то там увидим что:

По сути, данный комплекс ПО содержит в себе настроенный LAMP, консольную панель управления сервером, плюс дополнительные, необходимые для работы некоторых модулей 1C-Bitrix, пакеты. Весь софт настроен с учётом особенностей 1C-Bitrix, а именно:

установлены необходимые расширения (gd, zip, socket, mbstring)
включена поддержка short-тегов
заданы необходимые значения для параметров memory_limit, max_input_vars, safe mode, opcache.vali_stamps, opcache.revali_freq, mbstring.func_overload, default_charset, display_errors и др.
установлен одинаковой часовой пояс для БД, php и на самом сервере
и др.

Это позволяет в большинстве случаев не заниматься настройкой сервера и его тюнингом.

Итак, у нас было 2 app сервера (назовём их app01 и app01), 2 db сервера (db01, db02), 1 сервер под кэширование (cache01, ну вы поняли), точнее была идея реализовать структуру кластера подобным образом. Под этот план были получены 5 серверов, с установленными на них последними версиями centos7 (к сожалению, debian, ubuntu, fedora, rhel и др. не подходят), кроме os на серверы больше ничего не устанавливалось.

В дальнейшем работа пошла по следующему плану:

1. Установить bitrixenv

Установка не подразумевает сверхъестественных знаний linux или администрирования. Заходим на каждый сервер через ssh и выполняем такие команды:

Ставить bitrixenv необходимо на все серверы, которые планируется использовать в кластере. Даже если сервер будет работать только как инстанс memcached, bitrixenv необходим, т.к. позволяет управлять всем кластером из основного сервера.

2. Настроить bitrixenv

Т.к. использовать весь этот зоопарк мы будем как кластер, то производить настройку серверов можно через меню окружения на app01. Для этого заходим на сервер через ssh, и запускаем файл /root/.sh. При первом запуске необходимо задать пароль для пользователя bitrix (аналогичную операцию необходимо провести на всех серверах, где планируется запуск сайта):

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

Тут нам необходимо выбрать первый пункт меню. В процессе создания окружение запросит имя текущего сервера, тут то мы и указываем app01:

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

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

Теперь нам необходимо добавить в созданный пул все доступные серверы. Для этого воспользуемся первым пунктом меню и увидим такие варианты:

Настройку ролей серверов пока отложим на следующий шаг.

3. Перенос проекта

Если ваше приложение использует дополнительный софт, то самое время его установить и настроить. В нашем случае были установлены и настроены supervisord и RabbitMQ, т.к. приложение работало с использованием очередей.

Есть небольшой, но важный, нюанс. При переносе сайта в кластер, необходимо чтобы на сайте были отключены модули scale и cluster, а в окружении кластера, в которое планируется перенос, серверы пулла были не задействованы. Включать в работу серверы кластера необходимо только после того, как сайт будет перенесён и развёрнут на основном сервере. В противном случае сайт не сможет корректно определять серверы кластера.

4. Включение кластерного режима работы

4. Configure memcahed servers > 1. Configure memcached service

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

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

Пришло время добавить второй app-сервер. Для этого переходим по пути

8. Manage web nodes in the pool > 1. Create web role on server,

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

Обратим внимание на то, что в колонке Roles напротив сервера app02 указана роль web.

Осталось разобраться с БД, её настройка занимает больше всего времени. Для начала вкратце объясню, как раздаются роли mysql в контексте bitrixenv. По-умолчанию на основном сервере кластера стоит master версия БД. В нашем случае необходимо было вынести БД на отдельный сервер и добавить ещё один сервер с slave-версией БД. В bitrixenv нельзя просто так взять и перенести master с одного сервера на другой)

Даём роль mysql_slave серверу, на который мы планируем перенести БД
На целевом сервере меняем роль mysql_slave на роль mysql_master (автоматом старый mysql_master переходит в режим mysql_slave)
Удаляем роль mysql_slave на исходном сервере, бывшем master
…
PROFIT.

Мы последовали этой логике таким образом:

3. Configure MySQL servers > 4. Create MySQL slave

Отлично, теперь переходим в

3. Configure MySQL servers > 5. Change MySQL master

Указываем app01 и ждём. В итоге должны увидеть примерно такой результат:

Наконец, все серверы подключены и настроены.

5. Тюнинг производительности

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

Выводы

В рамках данной статьи мы разобрали последовательность действий, необходимых для настройки кластера серверов на базе bitrixenv, а также некоторых возможных подводных камней. По итогам работы с bitrixenv, и кластером на нём, можем выделить плюсы и минусы данного подхода:

Итак, чтобы разобраться со всей этой темой, вам понадобится:

Базовые навыки работы с Git. Коммиты, пуши, пуллы и все такое.
Хостинг, поддерживающий подключение по SSH.
GitHub-репозиторий с поддержкой GitHub Actions (насколько я знаю, они работают везде, но мало ли).

Принцип

Вкратце скажу принцип работы всего этого действа: когда мы будем пушить данные в репозиторий, сработает GitHub Action, которому сказано подключиться к вашему хостингу по SSH и залить туда данные с помощью rsync.

Создание SSH-ключа

Итак, самое первое, что нам стоит сделать, это создать SSH-ключи – приватный и публичный. Лучше всего это делать непосредственно в консоли гита - Git Bash. Если же вы на Mac – подойдет и Терминал.

Открываем Git Bash, вводим следующую команду:

При использовании команды указывать парольную фразу не нужно.

Скриншот из консоли при вводе команды создания ключа

Данная команда создаст ключи и поместит их в папку .ssh на вашем ПК. К сожалению, не знаю, куда именно попадают ключи на Mac, но думаю вы легко найдете это в гугле. А на винде - C:\Users\ИмяПользователя.ssh. Если же вы откроете Bash в этой же папке - ключи попадут прямо в нее. Главное, не забудьте удалить их оттуда, чтобы они не попали в файлы репозитория!

В этой папке вы найдете ключи id_rsa и id_rsa.pub, приватный и публичный ключи соответственно.

Добавление ключей

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

Скриншот из cPanel, доступ по SSH

Добавляем id_rsa.pub в публичные ключи репозитория, если потребуется, авторизуем его (просто нажатием кнопки), и сохраняем.

Теперь идем в репозиторий GitHub, переходим в Settings, оттуда переходим в Secrets. Внутри нужно будет назвать секрет и ввести приватный ключ (сохраните его заранее в буфер обмена). Называйте ключ просто – key, вставляйте ключ и сохраняйте.

Готово, оба ключа введены и должны работать.

Пишем файл для деплоя

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

Итак, название файла deploy.yml
Внутри также указан name: Deploy
А далее указано действие, по которому сработает скрипт - on: push: branches: main . То есть, когда вы будете пушить что-то в ветку main – сработает скрипт. Конечно, если у вас другая ветка – можете поменять ее.
Далее указана "работа", или же jobs. Там описано, где именно будет запускаться все это и как. А также указан путь к ключам, как - run: echo "$" > "$HOME/.ssh/key" . Как раз тут и указано наше название ключа, key, которое мы писали в секретах.

И самая интересная для нас часть кода - это build и deploy.

Первая строка по факту равноценна привычному npm i , просто через ci установить все это на гите быстрее. Вторая же строка - это строка опциональная. Если у вас в проекте есть npm-скрипт build - используйте. Если у вас вообще нет npm-скриптов - удалите эти строчки.

Ну а здесь происходит буквально деплой данных. Сперва, командой cd app мы переходим в папку app (опять же, абсолютно опциональная вещь, если у вас просто нет папки app и никуда не надо переходить – можно убрать эту команду). Ну и далее для нас важна только строка, указывающая, куда все это деплоить:

Что дальше

Итак, файлик deploy.yml нужно поместить в ваш проект в специальную папку .github, чтобы гитхаб о ней узнал, и затем просто запушить проект.

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

Скриншот вкладки GitHub Actions с рабочим запуском deploy.yml

Заключение

Надеюсь, данная статья была вам полезна. Если же вам интересна видео-версия – в начале статьи есть видео, переходите и смотрите! До скорого!

Читайте также: