Евгений Крупченко

Просто какая-то каша из информации... ничего не понятно.

Т.е. pos.plr - это и есть ваш файл, который по фтп заливается? Файл состоит из одной этой строчки без перехода на новую?

Попробовал ваш скрипт и .plr файл - все четко работает, пробел на конце рисует во втором случае.

по фтп проверял закидывать (вместо создания прямо на сервере) - байт в байт передается.

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

AddCharset utf-8 .plr  - вообще не имеет смысла т.к. оно влияет лишь на отдачу этого файла апачем клиенту. Вы же читаете php скриптом прямо там (апач лишь php запускает).

Что это значит? По фтп в текстовом режиме?

Не видя вживую проблему ничего толком не понять.

Но можно попробовать упаковать в архив, забросить на сервер и там распаковать.

Вот не надо тут восхищенно возвышать спамеров и "разработчиков" их софта и принижать тех кто им противостоит.

Во-первых нужно разделить спам на 2 больших группы:

1) Тупой залетный.

Его отбить очень легко безо всяких капч. У меня защита от ботов на POST запросы стоит практически везде и за годы использования было всего пару "пробитий" контакт формы на одном сайте, где похоже использовали не совсем тупого серверного бота, а такого что и куки и javascript может. Более 99% спама таким образом отбивается (хотя конечно сильно зависит от сайта и интереса спамеров к нему).

2) Продвинутый, типа как на скрине выше. Который уже эмулирует браузер и главное, когда у спамера есть четкий интерес к конкретному сайту. Т.е. целенаправленный.

Лично не сталкивался, но как говорится, всегда можно найти болт с хитрой левой резьбой. Вот к примеру видим что он там ищет какие-то конкретные поля, что мешает сделать для каждого поля массив из сотни названий и рандомно (или по какой-то логике) генерировать их (принимающий скрипт конечно также обучить понимать это)? Это лишь один из примеров что первое в голову пришло. Можно нафантазировать много чего, обо что споткнутся почти все те "шаблоны".

Но и конечно ничего не защитит если спамить будет живая обезьяна. Но речь же про софт.

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

Ну допустим не 345.

Конкретно у nic.ua есть система скидок + бонусы копятся и можно тратить на продление доменов.

https://nic.ua/ru/rewards

Если у вас нет там скидки, значит и доменов не густо и паниковать не о чем.

Пушка просто, ракета а не хостинг 👍

А ТС'у не надо ничего, он из тех кто раз в пол года постанет что-то и исчезнет, плевать ему на ответы ваши. Возможно просто чей-то карманный аккаунт, тут таких полно.

Что вы (или кто-то тут на форуме) можете с этим сделать? Пишет же сетевой карты нет. Просто нет устройства. Кроме их поддержки никто ничем не поможет.

Не сочтите за язвление (разве что самую каплю), но просто оставлю это тут:

Цитата с https://habr.com/ru/post/516892/ :

Попробуйте спросить у Брюса:

https://searchengines.guru/ru/forum/1014166/page2#comment_16675429

Суть так и не улавливаете.

Если ваш web-сервер читает/исполняет и тот секретный файл и другой, который кто-то чужой по фтп закинет - все, это конец :)

Что его остановит сделать <?echo file_get_contents('secret.php');?>

Суть же в том что вы пытаетесь разграничить доступ в одной среде (ftp) - да, это можно сделать через .ftpaccess (выше расписано).

Но в другой середе у вас apache (или что там) имеет доступ (и должен иметь, раз говорите он должен по http открываться) ко всему. И как вы себе представляете?

Если уж совсем пофантазировать, то можно сделать что-угодно. Например:

1) Делаем владельцем папки сайта и всех его файлов user1, на папки 770, на файлы 660 права.

2) Секретный ваш secret.php делаем владельцем user2 и тоже 660.

3) Запускаем 2шт - apache1 от имени user1 и apache2 от user2

4) Nginx проксирует запросы этого сайта к backend apache1 - и соответственно сайт открывается нормально весь, кроме secret.php - к нему у user1 доступа нет и пишет 403 firbidden.

5) Делаем в конфиге nginx исключение типа location /secret.php... который проксироваться будет уже к apache2.

6) Ну и по фтп заходит user1 и имеет доступ ко всем файлам/папкам сайта, короме конечно же secret.php

7) Даже если он закинет php shell или просто свой любой скрипт и попытается открыть secret.php - доступа у него не будет т.к. владельцем его является user2, а 660 - последняя 0 означает что для всех остальных доступа нет. Но при этом сайт и файл этот по http будут полноценно работать.

И теперь спрашивается стоит ли оно этой всей мороки?

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

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

Во-первых открываем его конфиг(и) и ищем есть ли allowoverride on, если нет - добавляем. Правда не знаю может ли эта панелька перезаписать позже конфиг.

В нужной папке создаете файл .ftpaccess с такого плана содержимым:

hidefiles (dir1|index.htm)$
<limit all>
ignorehidden on
</limit>

Т.е. вроде понятно - перечисляете какие файлы/папки спрятать. Или наоборот: hidefiles !(dir1|index.htm)$ - спрятать все, кроме dir1 и index.htm

Спрятать не от всех, а только определенного пользователя: hidefiles (dir1|index.htm)$ user nesokolov (или опять же через user !sokolov спрятать от всех кроме такого-то юзера)

(справка)

Ниже limit all нужно т.к. без него допустим папку dir1 по фтп видно не будет, но если знать что она там есть, то можно написать cd dir1 и невозмутимо попасть в нее 😏

Однако... надо смотреть не вырванно из контекста, а какие конкретно задачи вы преследуете. Дать кому-то чужому доступ на фтп?

Меня периодически клиенты спрашивают о подобном и объясняю, что (хотя конечно кто знает как там у вас все настроено) это не имеет никакого смысла.

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

К примеру он закинет php или cgi скрипт свой, которым вместо ftp сервера, через web сможет открыть все куда есть доступ у этого пользователя.

Т.е. в вашем случае вы типа спрятали файлы и папки какие-то, но что помешает php скриптом получить к ним доступ?

Не исключаю что из-за этого и нет такого функционала в панели вашей, т.к. смысла нет.

Пользую с 14го года

Глянул за 3 прошлых месяца... МТС меня ненавидит 😎