Активность

В процессе поиска и покупки доменных имён многие пользователи сталкиваются с неожиданной и крайне неприятной ситуацией: домен, который они только что искали через крупного регистратора вроде GoDaddy, внезапно оказывается купленным сторонней компанией. Далее за покупкой следует спекулятивное предложение о перепродаже домена за значительно более высокую цену. Данная практика вызывает обоснованные подозрения и имеет явные юридические последствия. Конкретный случай: DigiMedia.com, L.P. и Scott Day Недавно мной был произведён поиск доменного имени через одного из популярных регистраторов. В течение короткого времени домен оказался зарегистрированным на следующую контактную информацию: Имя: Scott Day Организация: DigiMedia.com, L.P. Адрес: 1057 N. Bryant, STE 150B, Edmond, OK, 73034, US Телефон: +1.9406911800 Проведённое мною дополнительное исследование показало, что компания DigiMedia.com, L.P., а также непосредственно Scott Day, фигурировали в различных юридических разбирательствах, связанных с так называемыми «сомнительными сделками с доменами». Самый известный пример, это наверное ситуация с Gold Coast Tourism Corporation v. DigiMedia.com, L.P. Дело: WIPO Case No. D2013-1733 Суть: Истец утверждал, что DigiMedia использует домен goldcoast.com недобросовестно, предлагая его продажу за 1 миллион долларов. Решение: Панель установила, что DigiMedia зарегистрировала домен в 1997 году, за восемь лет до регистрации товарного знака истца. Жалоба была отклонена, и истец был признан виновным в попытке обратного захвата домена. Источник: https://www.wipo.int/amc/en/domains/decisions/text/2013/d2013-1733.html Кто такой Scott Day и чем занимается DigiMedia.com, L.P.? Scott Day — известная фигура в мире "доменных инвестиций". Его компания DigiMedia.com, L.P. накапливает крупные портфели доменов, в том числе премиальные имена общего назначения, и занимается их последующей перепродажей по ценам, значительно превышающим рыночные. Основной механизм работы таков: Отслеживание интереса. Сайты-регистраторы или связанные с ними посредники фиксируют запросы пользователей на проверку доступности домена. Быстрая покупка. Если доменное имя потенциально ценно, оно оперативно регистрируется на третье лицо, часто на компанию типа DigiMedia.com. Предложение перепродажи. Новый владелец предлагает покупателю, проявившему интерес, приобрести домен за сумму, которая может в сотни и тысячи раз превышать стандартную цену регистрации. Возможные юридические последствия Данная практика на грани допустимого: Киберсквоттинг. Если домен содержит зарегистрированный товарный знак или вводит в заблуждение, это может считаться нарушением антикеберсквоттерских законов, например, в США это Anti-Cybersquatting Consumer Protection Act (ACPA). Нарушение конфиденциальности запроса. При наличии доказательств передачи или использования информации о запросах в коммерческих целях возможны судебные иски против регистратора или аффилированных компаний. Нечестная конкуренция. В ряде стран спекулятивная покупка доменов с целью последующей продажи может квалифицироваться как форма недобросовестной коммерческой практики. Известные судебные дела Я привел пример выше с указанием ссылки на источник, но это не единичный случай. Ранее Scott Day и связанные компании упоминались в судебных процессах, например: Иски со стороны владельцев товарных знаков за попытку регистрации доменов, схожих с их брендами. Жалобы на спекуляцию и монополизацию доменного пространства. Хотя в большинстве случаев DigiMedia.com действовала в рамках закона, их действия вызывали общественное осуждение и подвергались расследованию. Как избежать подобных ситуаций Поскольку вероятность перехвата домена после запроса реальна, необходимо соблюдать следующие меры предосторожности: Использовать сервисы WHOIS-запросов через проверенных нейтральных операторов, которые не связаны напрямую с регистраторами. Проверять доступность домена через терминал командой whois напрямую, без использования сайтов. Регистрация без промедления. Если найдено подходящее имя, нужно немедленно его регистрировать, не откладывая ни на минуту. Использовать регистраторов с репутацией, которые официально заявляют о невмешательстве в запросы пользователей и соблюдают политику конфиденциальности. Анонимный поиск. Скрытие IP-адреса и использование сервисов, не отслеживающих действия пользователей, минимизирует риск. Заключение Ситуация, при которой крупные сайты и посредники перехватывают домены после пользовательских запросов, остаётся серьёзной проблемой рынка. Несмотря на существование законодательных рамок, ответственность таких действий в судебной практике крайне ограничена и требует длительных разбирательств. В случае столкновения с подобной ситуацией рекомендуется сохранять все доказательства, фиксировать дату и время первоначального запроса, а также обращаться за консультацией к специалистам в области права интеллектуальной собственности. На будущее необходимо проявлять максимальную осторожность при проверке и покупке доменов, поскольку каждый необдуманный шаг может привести к потере уникального имени или вынужденной переплате.

Раздача поддоменов третьим лицам без строгого контроля и проверок представляет собой крайне рискованную практику, которая может иметь серьёзные юридические, технические и репутационные последствия для владельца основного домена. Рассмотрим причины, по которым это категорически не рекомендуется. 1. Ответственность за действия на поддоменах Основной домен (example.com) и его поддомены (user.example.com) юридически и фактически связаны. По сути, любой контент, размещённый на поддомене, воспринимается как часть инфраструктуры основного домена. В случае нарушения законодательства — например, размещения запрещённых материалов, фишинговых страниц или вирусного кода — претензии со стороны контролирующих органов, хостинг-провайдеров и других заинтересованных сторон будут направлены в первую очередь к владельцу основного домена. В судебной практике во многих странах домен и все его поддомены считаются единой зоной ответственности владельца. 2. Репутационные риски и блокировки Репутация основного домена напрямую зависит от поведения поддоменов. Если на одном из поддоменов будет размещён спам, вредоносное ПО или начнётся рассылка фишинговых писем, это повлечёт за собой: Появление домена в чёрных списках (DNSBL, SURBL и других системах антиспама); Снижение рейтинга доверия в поисковых системах (Google, Bing и др.); Блокировки со стороны провайдеров и почтовых служб; Потерю доверия аудитории и клиентов. Восстановление репутации домена может занять месяцы и потребовать значительных финансовых и временных затрат. 3. Технические угрозы безопасности Передача управления поддоменом подразумевает делегирование части инфраструктуры. В случае неправильной настройки возможно: Утечка данных основного домена через неправильную конфигурацию серверов (например, общие куки между поддоменами); Использование уязвимостей для атак на пользователей основного сайта (например, через поддельные формы входа); Проведение атак типа DNS Rebinding и CSRF через слабо защищённые поддомены; Перехват сессий пользователей основного сайта в случае общей авторизации. Если злоумышленник получит контроль над поддоменом, он сможет использовать его для подрыва безопасности всего проекта. 4. Юридические и финансовые последствия Размещение запрещённой информации на поддомене может привести к: Искам со стороны третьих лиц; Уголовной ответственности по законам той юрисдикции, в которой зарегистрирован домен; Блокировке домена на уровне регистратора; Прекращению обслуживания со стороны хостинг-провайдера; Наложению штрафов или даже уголовному преследованию в зависимости от тяжести нарушений. Кроме того, в случае претензий от крупных компаний или организаций юридическая защита потребует значительных расходов. 5. Трудности в отслеживании и управлении Даже если предполагается выдача поддоменов "знакомым" лицам с "хорошей репутацией", без профессиональной системы аудита и мониторинга становится невозможно: Контролировать размещаемый контент в режиме реального времени; Обеспечивать регулярные обновления безопасности для всех сервисов на поддоменах; Следить за исправлением инцидентов безопасности в кратчайшие сроки. Любая задержка в обнаружении инцидента будет стоить потери репутации, данных и клиентов. 6. Сложности с применением политик безопасности (CSP, HSTS) Многие современные политики безопасности работают на уровне всего домена и его поддоменов. Например: Политика Content Security Policy (CSP) должна быть согласована для всех ресурсов на всех поддоменах, иначе возможны обходы защиты; Политика HTTP Strict Transport Security (HSTS) может применяться к поддоменам, что делает невозможным исключение скомпрометированного поддомена без потери общего уровня безопасности. Выдавая поддомен посторонним, вы теряете возможность полноценно управлять политиками безопасности. 7. Риски при эксплуатации wildcard SSL-сертификатов Если основной домен использует wildcard-сертификат (*.example.com), то все поддомены автоматически считаются защищёнными данным сертификатом. Это даёт обладателю доступа к поддомену возможность: Перехватывать и расшифровывать зашифрованный трафик; Проводить MITM-атаки внутри локальных сетей; Скомпрометировать безопасность основного домена через ложные сервисы. Выдача поддомена фактически равнозначна предоставлению части сертификата безопасности. Как правильно организовать управление поддоменами Если по объективным причинам необходимо делегировать поддомены, следует использовать следующие меры: Заключать юридически оформленные соглашения, предусматривающие ответственность за содержание и безопасность; Выдавать отдельные субдоменные зоны через отдельные аккаунты управления DNS; Настраивать отдельные SSL-сертификаты для каждого поддомена, избегая wildcard-сертификатов; Использовать системы мониторинга для контроля активности и целостности контента на поддоменах; Регулярно проводить аудит безопасности и своевременно отзывать доступ при малейших подозрениях на нарушение. Заключение Раздача поддоменов незнакомым или недостаточно проверенным лицам — это прямая угроза безопасности, репутации и юридической защищённости всего проекта. При отсутствии строгой политики контроля даже один скомпрометированный поддомен может уничтожить многолетние усилия по построению надёжной и авторитетной онлайн-платформы. Ответственный администратор обязан рассматривать любую передачу управления поддоменом как выдачу полномочий высокого уровня риска, требующую максимально тщательной проверки и постоянного надзора.

В последнее время участились случаи, когда в различных сообществах, чатах и форумах (в том числе связанных с Telegram-ботами, Discord-интеграциями, платёжными системами и другими API) пользователи начали запрашивать API-токены под предлогами "настройки", "проверки", "автоматизации", "отладки", "быстрой помощи" и т. д. В большинстве случаев это попытка обмана с целью получить полный доступ к вашему сервису, боту или даже данным. Что такое API-токен? API-токен (API key, access token) — это уникальный ключ, предоставляемый системой (например, Telegram Bot API, Discord API, Google API), с помощью которого можно аутентифицировать и авторизовать приложение или пользователя для выполнения различных операций. Это своего рода "пароль", но зачастую с ещё более широкими возможностями, включая: Управление сообщениями, файлами и действиями от имени пользователя или бота. Доступ к данным, включая закрытые и конфиденциальные. Настройку и удаление сущностей (ботов, баз данных, каналов, чатов). Использование сторонних сервисов от вашего имени. Передача токена = передача полного контроля. Практический пример: Telegram Bot API Если вы создаёте Telegram-бота через @BotFather, вы получаете примерно такой токен: 123456789:AAHd3uEiXUZfP4lqdrL2U7yf0g7KZ6DdV8Y Это всё, что нужно злоумышленнику, чтобы: Читать и пересылать все сообщения, отправленные боту. Массово отправлять спам через вашего бота. Использовать вашего бота для фишинга, обмана и распространения вредоносных ссылок. Получить ваш IP (если токен используется на вашем сервере и не ограничен). Заблокировать или удалить бота (через команду /deletebot, если зайти через подделанный интерфейс). Получить доступ к базе данных, если в логике бота реализованы обращения с командами вида /sql select * from users. Кроме того, Telegram в таких случаях почти всегда блокирует или ограничивает бота, а ваш аккаунт может попасть в список подозреваемых, даже если вы стали жертвой. Распространённые предлоги, под которыми просят токен "Скинь токен, я настрою тебе бота, сам не раз настраивал". "Мне нужен только доступ на пару минут, я протестирую webhook". "Скинь токен, я добавлю своего бота в твой канал". "Я напишу для тебя скрипт, но мне нужен токен". "Ты не умеешь — дай токен, сам всё сделаю". Это всё примеры социальной инженерии. Никогда не передавайте API-токены, даже если собеседник кажется "профессионалом". Злоумышленники зачастую грамотно копируют манеру общения технических специалистов и могут выдать себя за разработчика, системного администратора или даже сотрудника поддержки. Что делать, если вы уже передали токен Немедленно отозвать токен, через BotFather командой /revoke И сгенерировать новый токен. Проверить логи и действия. Посмотрите, были ли неожиданные действия, особенно связанные с рассылками, новыми командами или вызовами API. Заменить все привязанные ресурсы. Если токен имел доступ к сторонним системам, необходимо сменить пароли и ключи доступа. Провести аудит безопасности. Особенно если токен был задействован на сервере. Возможно, требуется пересборка контейнеров, обновление зависимостей, смена SSH-ключей и очистка кэша. Как правильно работать с токенами Храните токены только в конфигурационных файлах вне публичного доступа. Никогда не публикуйте токены в открытых репозиториях (GitHub и т. п.). Используйте .env файлы и переменные окружения. Настраивайте ограничения на уровне IP, если это поддерживается. Реализуйте систему логирования всех вызовов API. Реализуйте автоотзыв (revoke) при подозрительной активности. Включите двухфакторную аутентификацию (если возможно). Передача API-токена третьему лицу — это равнозначно передаче ключей от квартиры с указанием адреса. Независимо от цели — будь то Telegram, Discord, OpenAI, GitHub, Google или любая другая система — никогда не передавайте токены, особенно незнакомым или малознакомым людям. Это создаёт угрозу не только вашему проекту, но и всей вашей цифровой инфраструктуре. Если вы хотите, чтобы кто-то помог вам с интеграцией — пусть делает это через pull-request, TeamViewer, ssh-ключ или в заизолированной среде, но не через прямую передачу ключей доступа.

Ситуация, в которой пользователь сталкивается с резким отключением рабочего компьютера, сопровождающимся неспособностью последующего нормального запуска, встречается достаточно часто. Если при попытке включения ПК вентиляторы начинают вращаться, но буквально через секунду всё обесточивается — это серьёзный симптом, напрямую указывающий на возможную неисправность блока питания (БП). Ниже подробно разбирается, почему именно блок питания с высокой долей вероятности является источником проблемы, какие внутренние механизмы это подтверждают, и как провести диагностику и подтвердить или опровергнуть подозрение. Описание симптомов Исходная ситуация следующая: ПК был включён и работал нормально. В какой-то момент произошёл резкий, самопроизвольный сбой питания — выключение без предварительных зависаний, артефактов, синих экранов или прочих программных предвестников. При попытке включить его снова вентиляторы на процессоре, видеокарте и корпусе могут кратковременно стартовать, но через секунду (иногда меньше) полностью останавливаются. Далее либо наступает полное молчание, либо повторное нажатие кнопки Power вызывает ту же картину — кратковременная подача питания и мгновенное отключение. Технический анализ — почему подозрение падает на блок питания Такое поведение чаще всего связано с срабатыванием систем защиты блока питания. Современные ATX БП оснащены набором защит, среди которых: OVP (Over Voltage Protection) – защита от перенапряжения; UVP (Under Voltage Protection) – защита от пониженного напряжения; OPP (Over Power Protection) – защита от превышения мощности; OCP (Over Current Protection) – защита по току; SCP (Short Circuit Protection) – защита от короткого замыкания. Если какая-либо из этих защит фиксирует отклонение от норм, БП мгновенно отключает питание, иногда не включаясь вовсе до сброса состояния (например, отключением кабеля питания на 10–30 секунд). Также возможно, что внутри БП вышел из строя один из силовых компонентов, таких как: ШИМ-контроллер, MOSFET-ключи, силовые диоды или транзисторы во вторичных цепях. Такие повреждения могут приводить к неустойчивому запуску или вообще невозможности выдать стабильное напряжение, после чего защита инициирует отключение. Исключение других причин Чтобы подтвердить или опровергнуть версию с неисправным блоком питания, требуется исключить влияние других компонентов. Материнская плата: Если бы плата вышла из строя, но БП исправен — при включении БП обычно продолжал бы работать (вентиляторы крутились бы стабильно, подсветка загоралась и т.д.), даже если система не проходила POST. Мгновенное отключение – не характерно. Процессор: Даже при отсутствии CPU большинство плат при запуске удерживают подачу питания, но не проходят POST и выдают диагностическую индикацию (звуковую или LED, если она есть). Оперативная память: Наличие или отсутствие ОЗУ не влияет на старт питания. Система не загрузится, но питание будет присутствовать. Видеокарта: При неисправной или отсутствующей видеокарте (если нет встроенной графики) система не покажет изображение, но также будет работать БП, вентиляторы будут крутиться. Короткое замыкание: Возможный сценарий — замыкание на материнской плате, в слоте PCIe или в периферийных устройствах. Проверяется частичным разбором. Пошаговая диагностика Шаг 1. Проверка БП без нагрузки (тест "запуска от скрепки") Отключите блок питания от всех компонентов. Возьмите скрепку и замкните зелёный провод (PS_ON) с любым чёрным (GND) на 24-пиновом разъёме. Подключите шнур питания и включите БП. Если вентилятор в блоке не запускается — БП однозначно неисправен. Если запускается — это не исключает неисправность под нагрузкой, но БП как минимум способен включиться. Шаг 2. Запуск с минимальной конфигурацией Отключите всё, кроме: материнской платы (с подключённым ATX 24-pin и CPU 4/8-pin), процессора с охлаждением. Не подключайте накопители, видеокарты, внешние устройства и даже клавиатуру. Если проблема сохраняется — переходим к следующему шагу. Шаг 3. Проверка другим блоком питания Это наиболее надёжный способ диагностики. Подключите к системе заведомо исправный БП достаточной мощности. Если система стартует — неисправность исходного БП подтверждена. Что может выйти из строя в блоке питания На практике в подобных ситуациях чаще всего отказывают следующие компоненты: Выходные электролитические конденсаторы – высыхают, теряют ёмкость, создают просадку напряжения; MOSFET транзисторы – пробой приводит к короткому замыканию; ШИМ-контроллер – если не выдаёт сигналы на ключи, БП не может стартовать; Диоды Шоттки во вторичной части – при пробое создают перегрузку; NTC-термисторы или варисторы на входе – выход из строя нарушает первичное питание. Возможна также деградация пайки, особенно у дешёвых БП — микротрещины вызывают нестабильную работу. Выводы и рекомендации Если при включении компьютера вентиляторы кратковременно стартуют и сразу же останавливаются, а до этого ПК внезапно выключился без видимых причин — наиболее вероятная причина неисправности кроется в блоке питания. Подобное поведение указывает на срабатывание внутренних защит, либо на отказ компонентов, неспособных обеспечить стабильное питание даже в простое. Рекомендовано: Провести тест на «скрепку». Проверить запуск системы с минимальной конфигурацией. При возможности — подключить исправный БП. Ни в коем случае не продолжать попытки запуска с повреждённым БП — это может привести к повреждению материнской платы и других компонентов. Если замена БП решает проблему — исходный блок подлежит разборке и ремонту только при наличии соответствующей квалификации. В противном случае — замена на новый, с учётом надёжности, сертификата 80+ и соответствующего запаса по мощности.

⚠️ Предупреждение: данная статья носит теоретический характер и основана на обобщённых наблюдениях по состоянию инфраструктуры в России. Информация получена в результате анализа открытых источников и поискового запроса «Подключить ADSL». Перед принятием решений, связанных с подключением или модернизацией интернет-соединения, рекомендуется дополнительно уточнять информацию у местных операторов связи и на местах. Несмотря на активное развитие мобильной связи и оптоволоконных технологий, доступ в интернет через телефонную линию (в том числе по технологии ADSL) в России всё ещё существует. Особенно это актуально для сельских и удалённых регионов, где модернизация сетей идёт медленно или не производится вовсе. В этой статье рассмотрим, как обстоят дела с телефонным интернетом в 2025 году, в каких регионах он ещё работает, почему он не исчез полностью и каковы перспективы. 1. Что такое ADSL и модемный интернет? ADSL (Asymmetric Digital Subscriber Line) — это технология передачи данных по медной витой паре (обычной телефонной линии). Она позволяет одновременно использовать одну и ту же линию как для телефонной связи, так и для доступа в интернет. При этом скорость передачи данных может достигать 24 Мбит/с (в случае ADSL2+), но зависит от качества линии и расстояния до АТС. Dial-up (аналоговый модемный доступ) — устаревшая технология, использующая голосовой телефонный канал. Теоретическая максимальная скорость — 56 Кбит/с, на практике — 28–40 Кбит/с. Для подключения требуется обычный модем (обычно внешний, с интерфейсом RS-232 или USB). 2. Где в России ещё используется ADSL и Dial-up? Наиболее активно ADSL используется в следующих случаях: Сельская местность, где отсутствует оптика и 4G-сети работают слабо или нестабильно. Малые посёлки, где сохранились действующие телефонные сети и АТС. Некоторые регионы Сибири, Урала, Дальнего Востока, особенно в районах с экстремальными климатическими условиями, где прокладка новых линий затруднена. Модемный интернет (dial-up) встречается крайне редко, но всё ещё работает: В отдельных деревнях, где есть только аналоговая телефония. Как резервный канал доступа при отсутствии других средств связи. В виде вспомогательного или аварийного способа получения данных (например, в некоторых учреждениях или охраняемых объектах). 3. Почему ADSL до сих пор жив? Основные причины: Отсутствие альтернатив: мобильный интернет может быть нестабильным, дорогим, с ограничениями по трафику. Низкая стоимость: у многих операторов ADSL-тарифы дешевле мобильных. Инфраструктура уже построена: несмотря на физический износ линий, в некоторых местах проще эксплуатировать существующее оборудование, чем прокладывать новое. Низкие потребности пользователей: пенсионеры, фермеры, малые предприятия — многие из них не нуждаются в высокой скорости или большом объёме трафика. 4. Проблемы эксплуатации ADSL Физический износ линий: медные кабели, особенно установленные 20–30 лет назад, подвержены окислению, повреждениям от влаги, замыканий. Низкая скорость и нестабильность соединения: особенно при плохом состоянии витой пары. Нехватка специалистов: в регионах сокращаются штатные единицы техников проводной связи. Ограничения на развитие: операторы отказываются от расширения или ремонта ADSL-сетей, ориентируясь на мобильные или оптоволоконные технологии. 5. Постепенный переход на альтернативы Во многих местах ADSL вытесняется: Оптоволоконными линиями (FTTx) — где есть возможность прокладки. Мобильным интернетом 4G/5G — при наличии покрытия и соответствующего оборудования. Радиоканалами (Wi-Fi-мосты, LTE-антенны) — в отдалённых районах. Пример: в Тульской, Курской, Воронежской, Нижегородской областях активно реализуются региональные программы цифровизации с прокладкой ВОЛС (волоконно-оптических линий связи) в сельские школы, ФАПы и администрации, попутно подключая частный сектор. 6. Перспективы: исчезнет ли ADSL полностью? Краткосрочно (2025–2027 гг.) — ADSL будет сохраняться как минимум в 5–10% сельских районов. Полностью отключать линии операторам пока невыгодно, особенно если они ещё приносят доход. Среднесрочно (до 2030 года) — ADSL практически исчезнет. Основными причинами будут: Массовый физический износ телефонной инфраструктуры. Дешевеющие оптоволоконные и LTE-решения. Уход поставщиков оборудования с рынка (ADSL-модемы уже почти не выпускаются). Dial-up — будет существовать исключительно как аварийная технология и в крайне изолированных местах (северные посёлки, охраняемые объекты, военные части). Заключение Интернет через телефонную линию в России ещё не исчез, но его время уходит. Он сохраняется в основном в силу отсутствия альтернатив, низкой стоимости и инерции старой инфраструктуры. Тем не менее, даже в самых отдалённых районах начинается переход к оптоволокну и беспроводным технологиям. ADSL, вероятно, останется в истории как переходная технология между аналоговой эпохой и цифровым будущим.

С 30 мая 2025 года в Российской Федерации вступает в силу закон №420-ФЗ, который вносит серьёзные изменения в сферу защиты персональных данных. Одним из ключевых положений нового закона стало введение «оборотных» штрафов за утечку персональных данных. Это означает, что размер санкций теперь будет зависеть от дохода организации, а не только от количества пострадавших лиц или тяжести нарушения. Что считается утечкой персональных данных? Под утечкой закон понимает: передачу, предоставление, распространение, открытие доступа ...персональных данных третьим лицам без законных оснований, в том числе при трансграничной передаче данных, например, при использовании Google-сервисов. Google Analytics и Google Формы под запретом без уведомления С января 2025 года Роскомнадзор обязал владельцев сайтов, которые используют Google Analytics, Google Формы, Firebase и другие зарубежные инструменты, передающие данные за пределы РФ, уведомлять ведомство об этом. Это требование вытекает из положений Федерального закона №152-ФЗ «О персональных данных», а также учитывает практику международной передачи данных. Почему Google-сервисы под запретом? Сервисы Google, по своей сути, передают собранные данные (включая IP-адреса, cookie, поведенческую аналитику) на серверы, находящиеся за пределами России. Таким образом, происходит трансграничная передача персональных данных, что требует соблюдения дополнительных условий: Уведомление Роскомнадзора. Получение явного согласия от пользователя. Гарантии со стороны принимающей стороны (в данном случае Google), соответствующие российским требованиям по защите ПД. Штрафы за нарушения: что грозит владельцам сайтов? За утечку персональных данных (закон №420-ФЗ): Физические лица: от 100 000 до 200 000 рублей; Должностные лица: от 200 000 до 400 000 рублей; Юридические лица и ИП: от 3 до 5 миллионов рублей (оборотные штрафы могут быть выше, в зависимости от доходов). За использование Google-сервисов без уведомления и согласия (п. 8 ст. 13.11 КоАП РФ): Физические лица: от 30 000 до 50 000 рублей; ИП: от 100 000 до 200 000 рублей; Юридические лица: от 1 до 6 миллионов рублей; при повторном нарушении — до 18 миллионов. Алгоритм действий для владельцев сайтов Если ваш сайт использует Google Analytics, Google Forms или другие зарубежные сервисы аналитики/обработки данных, необходимо предпринять следующие шаги: 1. Удалите код Google Analytics и других сервисов Удалите все фрагменты кода отслеживания с вашего сайта (включая встраиваемые формы, iframe, JavaScript-библиотеки и SDK, если речь идёт о мобильных приложениях). 2. Уведомите Роскомнадзор Перейдите на сайт Реестра операторов ПДн и: Войдите в личный кабинет организации; Подайте уведомление о прекращении трансграничной передачи данных, если вы ранее передавали их за рубеж; Либо подайте новое уведомление о трансграничной передаче, если хотите использовать эти сервисы легально. Срок рассмотрения уведомления — до 10 рабочих дней. 3. Обновите политику конфиденциальности Внесите в Политику конфиденциальности сайта следующие элементы: Указание на использование аналитических сервисов (Яндекс.Метрика, Google Analytics и др.); Перечень данных, собираемых этими сервисами; Ссылки на политики конфиденциальности сторонних сервисов; Подробности о трансграничной передаче данных. 4. Реализуйте форму согласия на обработку персональных данных Создайте и внедрите всплывающее окно или форму, в которой пользователь подтверждает согласие на: обработку ПДн, передачу ПДн третьим лицам, трансграничную передачу (если актуально). Форма должна быть реализована до начала сбора любых данных (cookie, IP, логов поведения). 5. Уведомите пользователей об аналитике На основании ч. 1 ст. 9 152-ФЗ и п. 18 условий использования Яндекс.Метрики и AppMetrica, необходимо: Явно указать, что на сайте ведётся аналитика; Обеспечить возможность отказа от сбора данных (например, через механизм opt-out); Указать контактные данные для отзыва согласия и получения информации. Заключение Роскомнадзор не запрещает использовать зарубежные сервисы аналитики, но требует строгого соблюдения законодательства. Игнорирование новых требований чревато не только штрафами, но и блокировкой ресурса. Рекомендация: владельцам сайтов, которые не имеют юридического отдела, целесообразно полностью отказаться от Google-сервисов в пользу российских аналогов, либо проконсультироваться с юристом для корректного оформления передачи данных и получения согласий.

Просмотр файла Deflection (Z1Z) Тема Deflection (Та, которую я использую на форуме) для Invision Community. Обновление от 23.04.2025 года: Минимальное количество изменений, лишь добавил следующий код в футер дизайна, который выводит ссылку на страницу с используемыми Cookie файлами на сайте. <li><a rel="nofollow" href='{url="app=core&module=system&controller=cookies" seoTemplate="cookies"}'>{lang='cookies_about'}</a></li> Добавил Ryancoolround Добавлено 23.04.2025 Категория Invision Community  

Задача: выбрать случайный элемент из группы и визуально его выделить, используя только HTML, CSS и JavaScript, без использования PHP или перезагрузки страницы. Это может пригодиться: для игр и развлечений (рандомайзер участников, вопросов, заданий); при реализации интерфейсов выбора (например, «удачи» или «случайной статьи»); для визуальных эффектов и демонстраций в обучающих целях. 🔨 Что нам потребуется: Контейнер с несколькими элементами (сетка); Кнопка для запуска выбора; Немного CSS для оформления; Скрипт на JavaScript для логики выбора и подсветки. 🧱 HTML + CSS + JavaScript: Полный пример <!DOCTYPE html> <html lang="ru"> <head> <meta charset="UTF-8"> <title>Рандомный выбор элемента</title> <style> .grid { display: grid; grid-template-columns: repeat(4, 1fr); gap: 10px; max-width: 400px; margin: 20px auto; } .item { background-color: #ddd; padding: 20px; text-align: center; border-radius: 5px; transition: background-color 0.3s; } .highlight { background-color: #ffa726; /* Цвет выделения */ color: #fff; } button { display: block; margin: 20px auto; padding: 10px 20px; font-size: 16px; } .forum-link { display: block; width: fit-content; margin: 30px auto; padding: 10px 20px; background-color: #1976d2; color: white; text-decoration: none; border-radius: 6px; font-weight: bold; transition: background-color 0.3s; } .forum-link:hover { background-color: #0d47a1; } </style> </head> <body> <div class="grid"> <div class="item">1</div> <div class="item">2</div> <div class="item">3</div> <div class="item">4</div> <div class="item">5</div> <div class="item">6</div> <div class="item">7</div> <div class="item">8</div> </div> <button onclick="highlightRandom()">Выбрать случайный элемент</button> <a href="https://z1z.org" class="forum-link" target="_blank">Перейти на форум Z1Z.ORG</a> <script> function highlightRandom() { const items = document.querySelectorAll('.item'); // Удаляем подсветку со всех items.forEach(item => item.classList.remove('highlight')); // Выбираем случайный индекс const randomIndex = Math.floor(Math.random() * items.length); items[randomIndex].classList.add('highlight'); } </script> </body> </html> 🧠 Как это работает? Сетка (.grid) создаётся с помощью CSS Grid, каждый элемент получает класс .item. Кнопка вызывает функцию highlightRandom() при каждом клике. Скрипт: получает список всех .item; очищает все предыдущие подсветки (classList.remove('highlight')); случайно выбирает один из них и добавляет класс .highlight. 🛠 Возможные улучшения Анимация мигания при выборе (через CSS keyframes). Запрет повторного выбора одного и того же элемента дважды подряд. Выбор нескольких случайных элементов. Сохранение истории выборов или отображение предыдущих. Интеграция с сервером — например, сохранять результаты выбора в базу. 📌 Заключение Этот пример — простой, но универсальный способ работы с визуальным выбором на клиентской стороне. Он идеально подходит для сайтов, не использующих сложные фреймворки, и может быть легко адаптирован под любую задачу. Демонстрация: https://z1z.org/labs/rand.html

22 апреля 2025 года в облачной инфраструктуре Timeweb Cloud произошёл масштабный сбой в работе баз данных PostgreSQL, затронувший все регионы. Данный инцидент длился около одного часа и стал предметом детального анализа как внутри компании, так и среди специалистов, использующих облачные решения Timeweb. Ниже приводится подробный разбор произошедшего. Хронология событий 14:40 (МСК) — в инфраструктуре Timeweb Cloud начались массовые перезапуски серверов с PostgreSQL. 15:10 (МСК) — инцидент был зафиксирован как внештатный, начато расследование. 15:40 (МСК) — все сервисы восстановлены, нормальная работа баз данных PostgreSQL полностью возобновлена. Общее время инцидента составило 60 минут. Причина сбоя Сбой был вызван внедрением нового расширения PostgreSQL, в процессе которого произошёл массовый перезапуск инстансов СУБД. Исследование показало, что в системе управления конфигурациями SaltStack использовался нестрогий порядок выполнения задач. В результате: Расширение было внедрено без должной последовательности действий. Серверы интерпретировали это как повод для перезапуска PostgreSQL. Все инстансы PostgreSQL во всех регионах оказались временно недоступны. Это техническое решение само по себе не предусматривало сбоя, однако несовершенство orchestration-сценариев стало критическим триггером. Поведение системы мониторинга Мониторинг Timeweb Cloud не распознал инцидент своевременно. Причина — ошибочная интерпретация массовых перезапусков как штатной части процесса обновления. Таким образом, алертинговая система не зафиксировала аномалию до момента, пока не поступили сигналы от внешних пользователей и не произошло ручное вмешательство. Это указывает на уязвимость мониторинга к массовым, но “легитимным” с точки зрения логики обновлений действиям. Последствия Пользователи, использующие PostgreSQL в рамках Timeweb Cloud, столкнулись с полной недоступностью своих баз данных. Приложения и сайты, опирающиеся на PostgreSQL, оказывались недоступны или демонстрировали ошибки доступа к БД. Другие СУБД (MySQL, MariaDB и др.) не пострадали. Важно: данные пользователей не были утрачены. После перезапуска все данные остались в целости и сохранности. Принятые меры По итогам инцидента Timeweb объявил о следующих мерах: Ужесточение порядка выполнения задач в Salt: Внедрение строгих зависимостей и порядка применения изменений. Применение валидации сценариев до продакшн-деплоя. Улучшение системы мониторинга: Разделение алертов по типу: штатные перезапуски, массовые нестандартные действия, отклонения по SLA. Внедрение эвристик на основе поведения кластера в целом, а не отдельных инстансов. Повышение прозрачности уведомлений: Быстрая публикация алертов и публичных пост-мортемов. Расширение каналов информирования (почта, Telegram-бот, панель управления). Рекомендации пользователям Для критически важных систем рекомендуется использовать механизмы резервирования на уровне приложений (replica DB, failover). Следует регулярно тестировать поведение приложений при временной недоступности БД. Рассмотреть внедрение собственных внешних проверок доступности сервисов, не полагаясь исключительно на внутренние системы мониторинга облачного провайдера. Заключение Данный инцидент ещё раз подчёркивает важность строгого контроля за автоматизированными процессами обновлений и роли мониторинга как первого рубежа в обнаружении сбоев. Timeweb Cloud оперативно устранил последствия, однако именно такие ситуации становятся катализатором улучшений в архитектуре, автоматизации и мониторинге. Следим за развитием событий и оценим, насколько эффективно будут реализованы озвученные меры.

Вряд ли сегодня для кого-то это станет открытием — значительная часть трафика в интернете не имеет никакого отношения к людям. Согласно многочисленным исследованиям, менее 50% интернет-активности приходится на действия реальных пользователей. Всё остальное — это бесперебойная, автоматизированная деятельность ботов, создаваемых как в легальных, так и в преступных целях. Что такое боты в интернете? Бот (сокращение от «робот») — это программа, которая выполняет действия в интернете автоматически, без участия человека. Боты бывают разными, но для удобства их делят на две основные категории: 1. Полезные боты Сюда входят: Поисковые краулеры (Googlebot, YandexBot и т.п.), индексирующие сайты. Системы мониторинга доступности сайтов. RSS-читалки. Боты социальных сетей (например, Telegram preview bot). Сервисы антиплагиата, сканеры сертификатов, валидаторы кода и др. 2. Вредоносные или подозрительные боты Это: Парсеры контента (воруют текст, изображения, структуру сайта). Автоматические спамеры (форумы, формы обратной связи, комментарии). Сканеры уязвимостей (в поисках уязвимых версий CMS, открытых API, старых библиотек). Brute force-боты (перебор логинов и паролей). Боты, эмулирующие поведение пользователей (накрутка поведенческих факторов). Статистика: интернет глазами аналитики По данным отраслевых отчётов (Imperva, Statista, Cloudflare), средний показатель распределения трафика по категориям в 2020–2024 годах выглядел следующим образом: Человеческий трафик: 45–49% Полезные боты: 15–20% Вредоносные и подозрительные боты: 30–35% Это значит, что реальный пользователь — уже не большинство. Сайт, который получает 1000 посещений в сутки, на деле может обслуживать только ~450 реальных человек, а остальное — искусственные запросы, потенциально угрожающие его стабильности и репутации. В реальном времени со статистикой по ботам можно ознакомиться здесь: https://radar.cloudflare.com/bots?dateRange=52w Почему это стало нормой? Причины роста бот-трафика 1. Доступность инфраструктуры С развитием облачных платформ (AWS, Azure, DigitalOcean) стало проще и дешевле запускать десятки и сотни автоматизированных агентов с анонимных IP. 2. Коммерциализация ботов Бот — это инструмент, и он давно стал товаром. Существуют сервисы, продающие: автоматические SEO-боты; системы массового комментирования; фальшивые переходы для рекламы; инструменты парсинга конкурентов. 3. Рост теневого рынка данных Контент сайтов, базы товаров, метаданные и поведенческие сценарии — всё это интересует ботов-парсеров, которые непрерывно сканируют сайты. 4. Проблемы этики у разработчиков Многие «белые» сервисы не ограничивают своих ботов в скорости, глубине обхода или количестве повторных запросов. В итоге нагрузка на сервер ощущается так же, как от вредоносных агентов. Чем опасны боты для сайта? 📌 1. Искажение статистики Аналитика перестаёт быть объективной. Метрика, GA, Piwik не могут различить умного бота и живого человека. Контент может «взлететь» в посещениях, но не иметь никакой отдачи (нет регистраций, нет комментариев, нет активности). 📌 2. Псевдооптимизация Администратор видит трафик — думает, что страница интересна. Вложение времени и ресурсов в улучшение бесполезной страницы. Потеря стратегического контроля над сайтом. 📌 3. Нагрузка на сервер Боты создают паразитную нагрузку на базу данных и сеть. Увеличение времени ответа. Возможны сбои и даунтайм при массированных заходах. 📌 4. Репутационные риски Поведенческие факторы портятся — высокая частота отказов, быстрые выходы. Сайт может попасть под фильтр в поисковых системах за подозрительную активность. Угроза блокировки от антибот-сервисов и систем защиты от накрутки. 📌 5. Прямой вред Атаки на формы входа (brute force). Поиск уязвимостей CMS, плагинов, админок. Подмена контента, внедрение скриптов, воровство данных. Почему фильтрация — сложная задача Даже современные системы защиты (Cloudflare, reCAPTCHA, WAF) не гарантируют 100% защиты от умных ботов. Причины: Боты научились эмулировать действия человека (движение мыши, задержки между кликами, скроллинг). Многие маскируются под популярные браузеры (Chrome, Firefox), подделывая User-Agent. Используются прокси и мобильные IP, что усложняет бан по диапазонам. Боты обучаются проходить простые капчи. Вывод Современный сайт существует в агрессивной экосистеме, где на одного реального посетителя приходится один или даже два автоматических агента. Эта реальность требует от администраторов пересмотра подходов к аналитике, безопасности и ресурсному управлению. Если раньше анализ поведения пользователей строился на простых метриках (посещения, время на странице, глубина), то теперь всё чаще приходится начинать с вопроса: "Это человек или бот?"

Основы CSS — Каскадные таблицы стилей CSS (Cascading Style Sheets) — это язык описания внешнего вида документа, написанного с использованием HTML или XML. Именно благодаря CSS мы имеем визуально привлекательные сайты: с оформленными кнопками, градиентами, анимациями, адаптивной версткой и динамическими эффектами. Если HTML — это скелет страницы, то CSS — её облик. Что делает CSS? CSS определяет: размер, цвет, отступы и расположение элементов; фон и изображения; шрифты, их стили и интерлиньяж; эффекты при наведении курсора и кликах; анимации, трансформации, адаптивность под разные экраны и прочее. Простой пример До CSS: HTML без стилей выглядит как сырой текст с базовой структурой. После CSS: Элементы получают оформление: шапка сайта — с градиентным фоном, кнопки — со скруглёнными краями и эффектом наведения, блоки — с тенями и разметкой по сетке. Разница — колоссальная. Базовый синтаксис CSS CSS можно подключать как во внешнем файле (style.css), так и писать прямо в <style> внутри HTML-документа (что чаще всего используется для тестирования). Синтаксис выглядит следующим образом: селектор { свойство: значение; } Пример: section { color: red; } селектор — элемент, к которому применяется стиль (например, div, p, .class, #id); свойство — характеристика (например, color, font-size, margin); значение — конкретная настройка свойства (red, 16px, auto и т.д.). Адаптивность: медиазапросы Чтобы сайт выглядел одинаково хорошо на разных устройствах, используются медиазапросы. Они позволяют применять стили только при определённых условиях, например, если ширина экрана менее 768 пикселей: @media (max-width: 768px) { section { color: red; } } Это основа адаптивной верстки: мобильные и десктопные версии сайта в одном коде. Встроенные стили CSS можно применять и напрямую к тегам: <section style="color: red;"></section> Но использовать такой подход на боевых проектах не рекомендуется. Он затрудняет сопровождение кода. Гораздо правильнее подключать отдельный CSS-файл: <link rel="stylesheet" href="style.css"> Расширенные возможности CSS CSS способен на большее, чем просто цвет текста. Например: Работа с SVG: svg { width: 120px; height: 68px; fill: green; } Использование изображений как фон: .block { background-image: url("image.svg"); } Добавление текста вне HTML: .block::after { content: "Дополнительный текст"; } Псевдоэлементы ::before и ::after: Позволяют визуально дополнить элементы интерфейса, не внося изменений в HTML-структуру. Анимации и фигуры CSS может рисовать фигуры (круги, треугольники), применять анимации, создавать интерактивные интерфейсы: @keyframes fadeIn { from { opacity: 0; } to { opacity: 1; } } .element { animation: fadeIn 2s ease-in; } Препроцессоры: LESS, SASS Базовый CSS не поддерживает переменные, вложенность, циклы. Для повышения гибкости используются препроцессоры: LESS — основан на JavaScript; SASS — один из самых мощных инструментов; Stylus — гибкий синтаксис. Пример кода на LESS: @main-color: #333; body { color: @main-color; } Препроцессоры компилируются в обычный CSS, позволяя значительно упростить сопровождение и масштабирование проекта. CSS в JavaScript-фреймворках Многие современные фреймворки используют концепцию CSS-in-JS. Например, в React есть styled-components, где можно прямо в JS-файле описывать стили: const Button = styled.button` background: #222; color: #fff; `; Это ускоряет разработку, но нарушает принцип разделения логики, структуры и стилей. Потому в классических веб-проектах по-прежнему рекомендуется использовать внешние CSS-файлы. Макетирование с помощью Flex и Grid Современный CSS предлагает две мощные системы компоновки: Flexbox — для линейного позиционирования (в строку или колонку); CSS Grid — для размещения элементов по двумерной сетке. Пример Flex: .container { display: flex; justify-content: space-between; } Пример Grid: .grid { display: grid; grid-template-columns: repeat(3, 1fr); } С их помощью можно реализовать любой макет — от простого блога до сложного веб-приложения. Как начать? Создайте файл style.css и подключите его к вашему index.html: <link rel="stylesheet" href="style.css"> Используйте редактор кода с поддержкой CSS: VS Code, Sublime Text, WebStorm. Используйте документацию: https://developer.mozilla.org/ru/docs/Web/CSS https://css-tricks.com Изучайте шаблоны и макеты на сайтах вроде https://codepen.io и https://freefrontend.com — это ускорит понимание. На заметку Старые методы вроде style>body{background: black} уже неактуальны, их используют только для демонстраций или устаревших проектов. Градиенты текста — пример современной стилизации: <span style="font-weight: bold; background: linear-gradient(to right, #ff0000, #fbff00); -webkit-background-clip: text; -webkit-text-fill-color: transparent;">СТИЛИЗОВАННЫЙ ТЕКСТ</span> Заключение CSS — мощный инструмент визуального оформления, обязательный к изучению каждому веб-разработчику. Он позволяет разделять контент и представление, создавать адаптивные интерфейсы, улучшать производительность сайтов за счет отказа от лишнего JavaScript. Глубокое понимание CSS — путь к созданию действительно качественных, эстетичных и удобных сайтов. Это не просто «оформление», это язык взаимодействия с пользователем на уровне визуального восприятия.

Иногда хочется навести порядок на сайте, убрать устаревшие или ненужные изображения — например, смайлы, которые больше не используются. Это простое руководство поможет вам удалить такие файлы с помощью FTP. Даже если вы никогда не работали с FTP-клиентами, этот процесс окажется для вас доступным. Что понадобится? FTP-программа. Рекомендую FileZilla — это бесплатный и удобный FTP-клиент. Скачать можно с официального сайта: https://filezilla-project.org/ Доступ к FTP-серверу (логин, пароль, адрес сервера) Немного внимания и желания навести порядок Пошаговая инструкция 1. Подключение к серверу Откройте FileZilla. Введите данные подключения: Хост — адрес вашего сайта (например, ftp.example.com). Имя пользователя и пароль — данные FTP-доступа. Порт — обычно 21. Нажмите «Быстрое соединение». 2. Найдите каталог со смайликами В левой части окна FileZilla — ваши локальные файлы, в правой — файлы на сервере. Перейдите по структуре каталогов до корневой папки сайта. Обычно это public_html/, htdocs/ или /www/. Найдите папку, где хранятся смайлы. Если не знаете точный путь — откройте на сайте любой смайл, щёлкните по нему правой кнопкой мыши и выберите "Открыть изображение в новой вкладке". Посмотрите путь к изображению в адресной строке браузера — это и есть путь к нужной папке. 3. Удалите ненужные изображения В правой части FileZilla откройте папку, содержащую смайлы. Выделите мышкой изображения, которые хотите удалить. Щёлкните правой кнопкой мыши и выберите "Удалить". Подтвердите удаление, если будет запрос. Внимание: будьте осторожны. Удалённые файлы невозможно восстановить, если у вас нет резервной копии. 4. Готово! Файлы удалены. Теперь вы знаете, как управлять содержимым сайта через FTP. Таким же образом можно удалить любые другие ненужные изображения, CSS-файлы, архивы, старые скрипты и прочее. Заключение Да, на первый взгляд это может показаться слишком простым — «гайд, как удалить файл». Однако для новичков, особенно тех, кого на уроках информатики учили только открывать Paint и рисовать домик с трубой, — это может быть отличной точкой входа в техническую сторону администрирования сайтов. Каждый администратор когда-то начал с малого — с первого входа на FTP, с первого удалённого файла, с первого осознания, что сайт — это не магия, а логика и структура. И если вы дочитали до конца — значит, вы на правильном пути.

Вопрос монетизации онлайн-сообществ представляет интерес как для администраторов, так и для участников. Существует распространённое мнение, что онлайн-форумы и сообщества могут приносить прибыль, но насколько это соответствует действительности? Ниже приводится обзор возможных источников дохода и типовых расходов, связанных с содержанием подобного проекта. Основные источники дохода онлайн-сообществ Прямая реклама Контекстная реклама (Google AdSense, Яндекс РСЯ) Баннерная реклама от прямых рекламодателей Партнёрские программы Платные функции Премиум-доступ к разделам форума Повышенные права или подписки (например, отключение рекламы) Продажа виртуальных товаров или донат-системы Интернет-магазин Продажа цифровых товаров: гайды, модификации, лицензии Физические товары, связанные с тематикой сообщества Пожертвования Добровольные переводы от участников сообщества Patreon, Boosty и аналогичные платформы Основные статьи расходов Программное обеспечение Лицензия на движок форума (например, Invision Community) Платные модули и расширения Системы аналитики, защиты и мониторинга Серверная инфраструктура VPS/выделенный сервер, оплата хостинга Резервное копирование, DDoS-защита Работа с контентом и модерацией Время администратора или команды модераторов Возможно — оплата труда сторонних специалистов Маркетинг и продвижение Покупка трафика SEO-оптимизация и закупка ссылок Продвижение в социальных сетях Типичная экономика небольшого сообщества По доступным наблюдениям, типовое некоммерческое сообщество в сегменте хобби/игровых тем за год может получить: Доход: от 0 до 10 000 рублей в год Расходы: от 15 000 до 50 000 рублей в год и более Итоговая разница, как правило, отрицательная. Такие сообщества существуют на личные средства администратора и воспринимаются как хобби, а не как инвестиция. Выводы Сообщество — не бизнес по умолчанию. Для того чтобы оно стало источником дохода, необходима активная работа по монетизации и масштабированию аудитории. Большинство сообществ убыточны. Особенно в случае отсутствия платных функций и фокусе на качественный контент без агрессивной рекламы. Цель администрирования должна быть чётко определена. Хобби, имиджевый проект, площадка для общения или коммерческая модель — каждая цель требует своей стратегии.

Многие владельцы игровых серверов сталкиваются с тем, что система банов SourceBans++, установленная на поддомене или в папке сайта, внезапно оказывается в индексе поисковых систем. Причём попадает туда весьма быстро, особенно в Яндексе. Это поведение я заметил давно, но основательно задумался о нём только сейчас — когда появилось время разобраться. Почему это может быть проблемой? На первый взгляд, нет ничего плохого в том, что ваш SourceBans++ попадает в выдачу. Однако с точки зрения SEO и технического администрирования, это создаёт определённые проблемы: Дублирование нерелевантного контента — страницы с банами не несут пользы основной аудитории сайта; Переизбыток "мусорных" URL в индексе — Яндекс тратит краулинговый бюджет на индексацию технических страниц, а не на действительно важный контент (новости, статьи, форум и т.п.); Уязвимость к автоматическому сканированию — злоумышленники могут использовать эти страницы для сбора IP-адресов, Steam ID, и других данных; Эстетика и репутация — появление внутренней панели банов в поиске может выглядеть неаккуратно для новых посетителей. Если вы занимаетесь продвижением сайта или просто стремитесь к чистоте структуры и индексации, от этого лучше избавиться. Как запретить индексацию SourceBans++? Рассмотрим типичный пример: Ваш сайт расположен по адресу: https://z1z.org/ Панель SourceBans++ доступна по пути: https://z1z.org/sourcebans/ (Адрес недействителен). Шаг 1: Подключение к файловой системе сайта Используем FTP-клиент, например FileZilla; Переходим в корневую директорию сайта (обычно /public_html/, /var/www/html/ или аналогичная, зависит от хостинга/конфигурации); Ищем файл robots.txt. Если он есть — открываем его. Если нет — создаём. Шаг 2: Настройка robots.txt Если файл уже существует, необходимо: Удалить все строки, разрешающие индексацию /sourcebans/, если таковые имеются; Добавить запрет на индексацию этой директории. User-agent: * Disallow: /sourcebans/ Если файл отсутствует, создаём новый robots.txt с минимальной конфигурацией: User-agent: * Disallow: /sourcebans/ Sitemap: https://z1z.org/sitemap.xml Замените sitemap.xml на фактический путь к карте сайта, если она у вас есть. Шаг 3: Проверка и ожидание После сохранения файла и его загрузки на сервер, проверьте его доступность: Откройте в браузере https://ваш_сайт/robots.txt Подождите некоторое время — изменения не вступают в силу мгновенно. Роботы Яндекса обновляют кэш robots.txt с разной периодичностью, иногда раз в несколько дней или неделю. Также рекомендуется использовать Яндекс.Вебмастер, чтобы вручную отправить файл на перескан. Почему теперь я не рекомендую запрещать SourceBans++ от индексации Со временем и накоплением опыта я изменил мнение. С практической точки зрения, публичная индексация банов даёт следующие преимущества: Удобный поиск по Steam ID/IP через Яндекс. Вбив в поисковик STEAM_0:X:XXXXXXX, вы мгновенно получаете информацию, была ли у игрока история нарушений. Если проект открыт для пользователей, полезно, чтобы данные о банах были легко доступны. Пользователи, которые ищут информацию о забаненных игроках, могут попасть на сайт через поисковик. Таким образом, если у вас нет конфиденциальных данных или особых требований к приватности — возможно, стоит оставить индексацию открытой. Компромиссный вариант: разрешить только список банов Если вы хотите сохранить SEO-чистоту, но оставить открытым доступ к списку банов — можно разрешить индексировать только главную страницу панели: User-agent: * Disallow: /sourcebans/ Allow: /sourcebans/index.php Sitemap: https://z1z.org/sitemap.xml Этот подход позволяет оставить минимальную часть данных в поиске, но не перегружать выдачу внутренними деталями каждого бана. Заключение Работа с robots.txt — это базовая, но важная часть технико-SEO-гигиены. SourceBans++, как часть инфраструктуры игровых серверов, требует внимания в плане конфиденциальности, индексации и взаимодействия с поисковыми системами. Следите за тем, что именно попадает в индекс и зачем, исходя из целей вашего проекта.

1. Проблематика хранения пользовательских медиафайлов Во всех современных веб-приложениях, поддерживающих пользовательскую активность (форумы, социальные сети, игровые платформы), существует необходимость хранения медиафайлов: аватаров, изображений, вложений и т.д. По мере роста пользовательской базы объём этих данных увеличивается, и вопрос их структуризации, оптимизации и периодической очистки становится критически важным. 1.1. Характеристика нагрузки Аватары: могут быть как загружены пользователем, так и сгенерированы автоматически (например, по первым буквам имени). Импортированные изображения: при использовании сторонней авторизации (OAuth) аватары импортируются локально, что означает дублирование данных, изначально хранящихся на внешних ресурсах. Частота изменений: часть пользователей может менять аватарки десятки раз в день, что ведёт к экспоненциальному росту количества изображений. 1.2. Риски бесконтрольного накопления Увеличение объёма хранилища → рост затрат на дисковое пространство; Усложнение резервного копирования; Повышение времени отклика при операциях с медиафайлами; Рост числа «мусорных» и устаревших файлов. 2. Принципы проектирования хранилища, пригодного для очистки Чтобы обеспечить управляемость, файловая система веб-приложения должна проектироваться с возможностью: Логической сегментации (по типу файла, времени создания, принадлежности пользователю); Обратной связи с базой данных — каждое вложение должно иметь цифровую привязку к сущности: посту, профилю, сообщению; Оперативного удаления по признакам устаревания — автоматизированный механизм сбора «осиротевших» файлов; Ротации аватаров — в идеале только один аватар должен быть активным у пользователя, а предыдущие — удаляться. Без соблюдения этих принципов любое долговременно работающее сообщество рано или поздно сталкивается с деградацией хранилища. 3. Проблемы, связанные с внешними методами авторизации Современные платформы предлагают OAuth-авторизацию через сторонние сервисы: Steam, Discord, Google, VK и т.д. Несмотря на удобство для пользователя, с технической точки зрения это создаёт множество потенциальных проблем: 3.1. Импортируемые данные При авторизации через внешнюю платформу: Пользовательский аватар импортируется на сервер; Может быть загружена информация профиля (имя, email); Нередки случаи, когда пользователь обновляет аватар в своём внешнем профиле, а сервер веб-приложения импортирует новое изображение → создаётся новое файловое тело. 3.2. Зависимость от стороннего API Изменчивость API: платформы часто меняют структуру API без обратной совместимости; Ограничения доступа: доступ к API может быть ограничен квотами или регионами; Уязвимость к внешним сбоям: падение платформы авторизации делает невозможным вход на сайт; Безопасность: валидация токенов требует дополнительной логики и сертификации. 3.3. Примеры нестабильности Сервисы неоднократно изменяют условия использования API, из-за чего на тысячах сайтов авторизация перестает работать; Google Places API с 2018 года стал платным, и это показывает, как бесплатный на старте сервис может неожиданно обрасти монетизацией; VK неоднократно менял схемы OAuth и политику работы с email, что ломало регистрацию на многих движках. 4. Рекомендации по минимизации зависимости Для обеспечения долгосрочной устойчивости веб-проекта рекомендуется: По возможности использовать только локальные методы авторизации; Сохранять единственный актуальный аватар, очищая предыдущие при загрузке нового; Регулярно выполнять аудит хранилища, включая проверку битых ссылок и устаревших файлов; Проектировать систему с возможностью массового удаления аватаров, шапок и других временных медиаэлементов; Предусматривать аварийные сценарии восстановления входа, не зависящие от внешних платформ. 5. Вывод С точки зрения системного администрирования и архитектуры, любая интеграция с внешними сервисами должна оцениваться не только по удобству, но и по рискам. Чем больше компонентов находятся вне зоны контроля администратора, тем выше вероятность их отказа, изменения условий предоставления услуг или полной недоступности. Оптимизация хранилища и отказ от лишних внешних зависимостей — это инвестиции в устойчивость, безопасность и прогнозируемость поведения системы.

Если при загрузке файлов на сайт вы видите сообщение, указывающее, что допустим только файл размером до 2 МБ, это означает, что серверные ограничения, установленные в конфигурации PHP, не позволяют загружать более крупные файлы. Ограничения задаются следующими директивами: upload_max_filesize — максимальный допустимый размер одного файла. post_max_size — максимальный общий объём данных, отправляемых методом POST (включает файлы и все поля формы). Ограничивающим значением является минимальное из двух. Если, к примеру, upload_max_filesize = 10M, а post_max_size = 8M, то реальное ограничение будет 8 МБ. Значение post_max_size всегда должно быть больше или равно upload_max_filesize. Изменение параметров PHP через ISPmanager Для изменения конфигурации выполните следующие шаги: Войдите в ISPmanager. Перейдите в раздел WWW-домены или WWW → PHP. В списке найдите используемую версию PHP. Выделите её и нажмите кнопку Настройка. В открывшемся окне найдите и измените следующие параметры: upload_max_filesize = 20M post_max_size = 25M Эти значения можно изменить на любое другое, соответствующее вашим требованиям. После сохранения конфигурации потребуется до 10 минут, чтобы изменения вступили в силу, так как ISPmanager пересобирает конфигурацию PHP. Если вы используете mod_php или php-fpm, важно убедиться, что изменения применены к нужному обработчику. Дополнительно при необходимости можно изменить: memory_limit — для обработки больших файлов. max_file_uploads — если необходимо загружать несколько файлов одновременно. Проверка применённых параметров После внесения изменений рекомендуется проверить текущие значения директив. Это можно сделать, создав PHP-файл с содержимым: <?php phpinfo(); ?> Откройте его через браузер и найдите соответствующие параметры. Убедитесь, что изменения применены к нужной конфигурации. Потенциальные риски при увеличении лимитов Увеличение лимитов загрузки файлов напрямую влияет на следующие параметры: Объём используемого дискового пространства. Временная нагрузка на оперативную память при обработке больших файлов. Влияние на производительность при массовой загрузке. Если значения заданы чрезмерно, это может привести к следующим последствиям: Быстрое заполнение диска при активной загрузке пользователями. Переполнение буферов и превышение лимитов оперативной памяти при обработке данных. Долгое время выполнения скриптов, приводящее к задержкам в обслуживании запросов. В критических случаях сервер может быть выведен из строя из-за нехватки свободного пространства или ресурсов. Рекомендации по безопасной настройке Увеличивайте лимиты только в пределах необходимого для задач вашего проекта. Ограничивайте допустимые MIME-типы и расширения файлов. Устанавливайте контроль ограничения размера файла на уровне фронтенда (JavaScript) и бэкенда (PHP). Регулярно очищайте временные директории, куда загружаются файлы (например, /tmp). Внедрите мониторинг свободного места на диске. Настройте автоматическое оповещение при достижении критического уровня использования файловой системы. Альтернативная настройка (при отсутствии ISPmanager) Если у вас нет доступа к ISPmanager или нужно внести изменения вручную, используйте один из следующих способов: a) В файле .htaccess (если используется Apache и mod_php) php_value upload_max_filesize 20M php_value post_max_size 25M b) В конфигурации php.ini (если доступна) upload_max_filesize = 20M post_max_size = 25M После этого потребуется перезапуск веб-сервера или PHP-FPM: systemctl restart apache2 # или systemctl restart php8.1-fpm c) Через ini_set() в PHP (только для скриптов, не применяется глобально) ini_set('upload_max_filesize', '20M'); ini_set('post_max_size', '25M'); Заключение Изменение директив upload_max_filesize и post_max_size — стандартная задача при настройке сайтов, работающих с пользовательскими загрузками. Однако их неправильная конфигурация может привести к перерасходу ресурсов, особенно на системах с ограниченным объёмом оперативной памяти и дискового пространства. Рекомендуется применять изменения обоснованно и контролировать поведение системы после их внедрения.

Одной из важных задач при кастомизации внешнего вида сайта является настройка всех элементов, включая ползунок прокрутки (или скроллбар). В некоторых случаях требуется изменить стандартный вид прокрутки, чтобы он гармонировал с общей темой оформления сайта, в данном случае с темой IPS 4.7.20. В этой статье рассмотрим, как это можно сделать с помощью небольшого фрагмента CSS-кода. Описание кода Предлагаемый код позволяет изменить внешний вид ползунка прокрутки, придавая ему вид, подходящий под стиль темы IPS 4.7.20. В частности, меняются следующие элементы: Ширина и высота полосы прокрутки — позволяет настроить размер ползунка. Фон области прокрутки — изменяется фон трека (области, по которой перемещается ползунок). Цвет и стиль самого ползунка — настройка внешнего вида "ползунка", который будет перемещаться по треку. Код для настройки ползунка прокрутки /* Ползунок прокрутки */ ::-webkit-scrollbar { width: 8px; height: auto; } ::-webkit-scrollbar-track { background: #212429; border-radius: 0px; } ::-webkit-scrollbar-thumb { background: #9bbb66; border-radius: 0px; } /* Конец ползунка прокрутки */ Разбор кода: ::-webkit-scrollbar — этот псевдоэлемент отвечает за сам ползунок прокрутки. В коде указано, что ширина полосы прокрутки будет 8px, а высота зависит от содержимого (автоматически). Это значение можно корректировать в зависимости от потребностей. ::-webkit-scrollbar-track — этот псевдоэлемент задает внешний вид области прокрутки (трека), по которой перемещается ползунок. В данном случае фон области задается темно-серым цветом (#212429), что гармонирует с общим дизайном темы IPS. Также указано отсутствие радиуса скругления углов. ::-webkit-scrollbar-thumb — этот элемент отвечает непосредственно за сам ползунок (или "пальчик"). В коде установлен зелёный цвет фона (#9bbb66), что соответствует стилю, используемому в оригинальной теме IPS. Радиус скругления также равен 0px, что делает углы прямыми. Как внедрить код в вашу тему? Для того чтобы применить этот стиль к ползунку прокрутки, выполните следующие шаги: Перейдите в Админцентр вашего сайта на платформе IPS. В меню выберите пункт Кастомизация. В нужной теме нажмите кнопку Редактировать HTML и CSS. В открывшемся окне выберите вкладку CSS. В поле Custom.CSS вставьте приведённый выше код. После вставки кода нажмите Сохранить. После сохранения изменений ползунок прокрутки будет отображаться в соответствии с новым стилем, гармонично вписываясь в дизайн вашей темы. Заключение Подгонка ползунка прокрутки под дизайн вашей темы может существенно улучшить внешний вид сайта и сделать его более современным и удобным для пользователей. В данной статье был представлен простой и эффективный способ изменить стандартный вид ползунка, чтобы он соответствовал оригинальной теме IPS. Внесенные изменения могут улучшить восприятие интерфейса и повысить удобство использования сайта.

После установки системы управления банами SourceBans, известной также как MATERIAL Admin - SourceBans++, пользователи могут столкнуться с ошибкой при попытке добавить первый сервер. Ошибка, которая может возникнуть, выглядит следующим образом: Deprecated: Function get_magic_quotes_gpc() is deprecated in /var/www/pro538/data/www/lk.cssold.ru/bans/includes/xajax.inc.php on line 705 Эта ошибка происходит из-за использования устаревшей функции get_magic_quotes_gpc(), которая была удалена в более новых версиях PHP. Давайте разберемся, что это за ошибка и как с ней справиться. Причины возникновения ошибки Функция get_magic_quotes_gpc() была частью PHP до версии 7.4. Ее использовали для определения, включены ли "магические кавычки" (magic quotes) в конфигурации PHP. Магические кавычки автоматически экранировали символы, такие как кавычки и обратные слэши, в данных, поступающих из форм или URL. Однако, начиная с версии PHP 5.4, эта функция была признана устаревшей, а в PHP 7.4 и выше она была полностью удалена. Соответственно, если ваш сервер работает на PHP версии 7.4 или выше, попытка выполнения этой функции вызывает предупреждение об устаревшей функции, как показано в ошибке. Решение проблемы Чтобы исправить ошибку, существует несколько подходов. Рассмотрим основные из них. 1. Понижение версии PHP до 7.3 Самым простым решением будет понижение версии PHP на сервере до 7.3. Эта версия еще поддерживает функцию get_magic_quotes_gpc(), что позволит избежать возникновения предупреждения. Для этого выполните следующие шаги: Откройте конфигурацию веб-сервера (например, Apache или Nginx). Установите PHP 7.3, если он не установлен. Включите или переключите вашу среду на PHP 7.3. Для Apache это может быть сделано через команду: sudo a2dismod php8.0 sudo a2enmod php7.3 sudo systemctl restart apache2 Перезапустите веб-сервер. После этого ошибка должна исчезнуть, так как версия PHP 7.3 поддерживает работу с функцией get_magic_quotes_gpc(). 2. Обновление кода для совместимости с новыми версиями PHP Если понижение версии PHP по каким-либо причинам невозможно, рекомендуется обновить код, исключив использование устаревших функций. В частности, следует заменить get_magic_quotes_gpc() на соответствующие проверки, которые работают в новых версиях PHP. Для этого в файле xajax.inc.php на строке 705 можно заменить: if (get_magic_quotes_gpc()) { на: if (ini_get('magic_quotes_gpc')) { Этот код будет работать аналогично, проверяя наличие включенной опции магических кавычек в конфигурации PHP, но без использования устаревшей функции. 3. Использование режима совместимости в PHP 7.4 и выше Если вы не хотите изменять код, вы можете использовать режим совместимости для устаревших функций в более новых версиях PHP, но этот подход не рекомендуется, так как он может привести к другим проблемам с безопасностью и производительностью в будущем. Тем не менее, если необходимо, можно использовать настройки конфигурации PHP для подавления предупреждений о устаревших функциях. Для этого добавьте в файл конфигурации php.ini следующее: error_reporting = E_ALL & ~E_DEPRECATED Этот параметр отключит отображение предупреждений о deprecated-функциях. Заключение Ошибка с get_magic_quotes_gpc() при добавлении сервера в SourceBans может быть решена несколькими способами. Если понижение версии PHP до 7.3 возможно, это может быть наиболее простым и быстрым решением. Однако для долгосрочной совместимости рекомендуется обновить код, чтобы исключить использование устаревших функций. В любом случае, важно поддерживать систему в актуальном состоянии, чтобы избежать проблем с безопасностью и производительностью.

Иногда в жизни каждого создателя проекта наступает момент, когда он задумывается, а стоит ли продолжать. Сомнения, страх неудачи, переживания о том, что усилия не оправданы, начинают одолевать. И в такие моменты может возникнуть желание все бросить, удалить, закрыть проект и начать что-то новое. Именно такое состояние я пережил как администратор на IP-Gamers.NET, и вот теперь я решил поделиться своими мыслями о проекте, который не имеет будущего. Однако стоит ли принимать такие решения в моменты разочарования? И можно ли научиться извлекать из критики пользу, а не становиться ее жертвой? Размышления о проекте и критика Все начинания, будь то сервер, сайт или сообщество, всегда сопряжены с риском. Когда проект только стартует, он неизбежно сталкивается с трудностями. Очень старый пост на форуме, с которым можно ознакомиться по ссылке IP-Gamers, обострил вопрос о том, что такое проекты вроде сервера IP-Gamers.NET, и стоит ли их продолжать, если они не могут соперничать с уже сложившимися решениями, такими как Солярис или Atlantis. Пользователь, оставивший сообщение, выразил сомнения относительно будущего серверов, утверждая, что ниша уже занята, а новое — всегда находит сопротивление. Он отметил, что проект может быть воспринимаем как очередная попытка, не имеющая смысла в условиях уже устоявшихся решений. «Почему создавать сервер, если уже есть такой-то и такой-то проект?» — вопрос, который часто задают те, кто не имеет полного представления о процессе создания и поддержания этих серверов. Это, безусловно, является одной из самых распространенных реакций критиков. Многие в условиях конкуренции чувствуют, что любой новый проект обречен на провал. Однако важно понимать, что критика, даже если она жестка, — это не всегда сигнал об окончании пути. Что стоит за критикой? Каждый проект, будь то сервер для игры или форум, требует огромных усилий, времени и вложений. Однако мало кто учитывает, что успех таких проектов редко бывает мгновенным. Мы живем в эпоху, когда интернет-проекты начинают существовать в условиях уже насыщенного рынка. Тем не менее, это не значит, что новые инициативы не имеют смысла. Нишу, даже если она занята, можно заново адаптировать, внести что-то новое и интересное, сделать проект уникальным в рамках уже существующего контекста. Создание чего-то нового — это всегда риск, и этот риск нужно принимать, если ты веришь в свою идею. Многие из нас сталкиваются с ситуацией, когда на проект начинают накатываться негативные отзывы. Это естественно, поскольку любой публичный ресурс не может угодить всем. Порой эти отзывы могут быть очень жесткими, но важно не принимать их близко к сердцу, а воспринимать как возможность для роста. Часто критика поступает не от профессионалов в области, а от людей, которые не понимают всей сложности работы, стоящей за созданием того или иного проекта. Это важно учитывать, когда речь идет о негативных отзывах и откликах. К примеру, в случае с IP-Gamers.NET пользователи могут не понять, что стояло за созданием уникальных серверов или конкретного подхода к игре. Их негатив — это не всегда конструктивная критика. Наоборот, оно может служить лишним стимулом для того, чтобы найти новые решения и подходы. Перспективы и их значение Зачем же все-таки продолжать, если проект подвергается таким жестким оценкам? Ответ кроется в самом процессе развития. Каждый проект, даже если он не находит признания у большинства с самого начала, имеет шанс на успех, если создатели проявляют упорство и готовы работать над улучшением. Есть масса примеров в истории технологий и интернет-сообществ, когда казалось бы, никому не нужная идея становилась успешной благодаря вере в нее и упорному труду. Взять хотя бы те же социальные сети — ВКонтакте появился не первым, но стал крупнейшей платформой, несмотря на наличие конкурентов. Что касается игровых серверов, то тот же IP-Gamers.NET, несмотря на наличие конкурентов, продолжает существовать как форум, и это уже достижение. Это говорит о том, что на рынке всегда есть место для новых идей, если они продуманы и представлены качественно. Особое внимание стоит уделить подходу к пользователям. То, что проект продолжает привлекать людей — это уже результат. Некоторые не видят ценности в начинающем проекте, не видят перспективы, но стоит помнить, что любой старт — это всегда риск, и только через годы работы становится возможным понять, насколько проект имеет ценность для пользователей. Миф об уникальности В большинстве случаев критика, как в примере с сервером, основана на мифе об уникальности. Говорят, что новый проект не может быть успешным, потому что в нем нет чего-то принципиально нового. Но стоит задуматься: почему все проекты, которые существуют, не могли бы быть "уникальными"? Почему не могут быть созданы серверы или форумы, которые будут по-своему интересны своим пользователям, даже если они кажутся похожими на другие? Конечно, их разработчики могут в чем-то ошибаться, но это не повод все закрывать. Напротив, ошибки — это ценный опыт, который помогает двигаться дальше. Как реагировать на критику и почему не стоит все удалять? Не стоит принимать критику как окончательный вердикт. Негативные отзывы — это не приговор, это возможность для улучшений. Когда проект не сразу обретает популярность или начинает сталкиваться с трудностями, нужно воспринимать это как часть пути. Возможно, некоторые идеи или направления были ошибочными, но важно помнить, что каждый шаг ведет к новым возможностям. В истории существует масса примеров, когда из-за ранней критики было принято решение закрыть проект, который позже стал успешным. Тем не менее, важно всегда помнить, что успех приходит к тем, кто не боится трудностей и готов продолжать работать, несмотря на первоначальные трудности. Завершая, стоит подчеркнуть, что проект, каким бы малым или незначительным он ни был на первый взгляд, имеет право на существование. И только через длительную работу, улучшения и развитие можно добиться того, чтобы проект был оценен по достоинству. В конце концов, критика — это всего лишь один из этапов на пути к успеху.

В истории IP-Gamers уже был реализован экспериментальный интерфейс для подачи заявок, жалоб и протестов. Он функционировал как полуавтоматическая система: при соблюдении определённых условий заявка автоматически направлялась ответственному администратору, а при определённых сценариях даже происходил автоматический разбан. Этот интерфейс значительно разгружал модераторов и администраторов, исключал «человеческий фактор» в некоторых решениях и работал достаточно эффективно с точки зрения технической реализации. Однако, несмотря на плюсы, у него был и существенный минус — заявки были конфиденциальными. Они были доступны только автору и модераторскому составу. С одной стороны, это решало вопросы приватности, но с другой — создавало замкнутую, непрозрачную систему. В этой статье мы рассмотрим, почему такая конфиденциальность является системной ошибкой и почему все подобные заявки должны быть публичными. Влияние на поведение сообщества Публичность заявок — это не просто формальность. Это важнейший социальный механизм. Заявки, протесты и жалобы, размещённые открыто, формируют поведенческие шаблоны у остальных участников сообщества. Например, если один из игроков, скажем, из клана Skill, подаёт заявку на пост администратора, это может побудить других участников кланов к аналогичной активности. Кто-то может поддержать кандидата, кто-то — выступить против. Но в любом случае запускается механизм участия и вовлечённости. Такие процессы делают сообщество живым, динамичным, способным к саморазвитию и самоочистке. Кроме того, новые пользователи, просматривая старые заявки, получают конкретные примеры: что указывать в заявке, какие аргументы работают, какой стиль подачи допустим, а какой — нежелателен. Это становится обучающим и регламентирующим инструментом, который не требует отдельной документации. Прозрачность как форма уважения к пользователю Один из ключевых аргументов в пользу публичности — это уважение к каждому участнику сообщества. Когда заявки закрыты, это воспринимается как закрытость власти. Пользователю как бы говорят: "Тебе не обязательно знать, кто будет решать твою судьбу на сервере, кто будет админом, кто формирует политику проекта". Такой подход создает информационный барьер, усиливающий дистанцию между администрацией и пользователями. В условиях сообщества, ориентированного на развитие и доверие, это недопустимо. Публичные заявки, напротив, позволяют каждому быть в курсе происходящего и участвовать в обсуждении. В оригинальном материале на форуме IP-Gamers этот момент подчёркивается особенно чётко. И действительно: игроки имеют право знать, кто будет их банить или снимать бан, кто будет следить за соблюдением правил, а кто — представлять сервер на внешних ресурсах. В условиях конфиденциальности теряется важнейшая вещь — взаимное доверие. Обратная связь от всех, а не только от модераторов Ошибочно считать, что оценивать заявку должен только модераторский или административный состав. В любом сообществе существует так называемая неформальная иерархия — люди, чьё мнение уважаемо и принимается большинством. Эти пользователи могут не иметь официальной должности, но именно их реакция на заявку часто важнее, чем сухая формальная оценка. Открытое обсуждение позволяет учитывать мнение опытных игроков, активных участников кланов, стримеров, картоделов — всех, кто имеет ценное понимание контекста. Они могут указать на поведение кандидата в прошлом, на его сильные или слабые стороны. Их участие формирует коллективную оценку, которая будет более объективной, чем суждение одного администратора. Ответственность и контроль Закрытые заявки создают иллюзию безнаказанности. Решение, принятое в кулуарах, нельзя оспорить или подвергнуть сомнению. Нет никакой гарантии, что оно не было основано на личной симпатии или антипатии, а не на реальных заслугах или фактах. Публичность заявок означает, что каждое решение подлежит проверке. Это — форма внутреннего аудита, встроенного в саму структуру сообщества. Если администратор или модератор принимает спорное решение, он знает, что это увидят другие. Это стимулирует его аргументировать свою позицию, избегать предвзятости и следовать регламенту. Заключение Система приватных заявок может быть удобной для администрации, но она вредна для сообщества в долгосрочной перспективе. Она подрывает доверие, ограничивает вовлечённость и исключает возможность коллективной оценки. Напротив, публичные заявки: способствуют обучению и росту новых участников, укрепляют связь между пользователями и администрацией, создают атмосферу прозрачности и честности, минимизируют риски предвзятых решений. IP-Gamers — это не просто проект. Это сообщество. А сообщество требует открытости.

Вот кстати простейший пример небольшого, очень минималистичного WEB приложения. Пример доступен по ссылке: https://z1z.org/imt/ <?php $result = ''; if ($_SERVER['REQUEST_METHOD'] === 'POST') { // Применяем фильтрацию и проверку ввода $weight = filter_input(INPUT_POST, 'weight', FILTER_VALIDATE_FLOAT); $height = filter_input(INPUT_POST, 'height', FILTER_VALIDATE_FLOAT); // Проверяем, что данные корректны if ($weight !== false && $height !== false && $weight > 0 && $height > 0 && $weight < 500 && $height < 300) { // Расчёт ИМТ $bmi = round($weight / (($height / 100) ** 2), 2); // Определение статуса ИМТ if ($bmi < 18.5) { $status = 'Недовес'; } elseif ($bmi < 25) { $status = 'Норма'; } elseif ($bmi < 30) { $status = 'Избыточный вес'; } else { $status = 'Ожирение'; } // Выводим результат $result = "Ваш ИМТ: $bmi — $status"; } else { // В случае некорректных данных $result = "Введите корректные значения веса и роста."; } } ?> <style> .container { background-color: white; border-radius: 8px; box-shadow: 0 4px 8px rgba(0, 0, 0, 0.1); padding: 20px; width: 300px; text-align: center; } h2 { color: #333; font-size: 1.5em; margin-bottom: 20px; } form { display: flex; flex-direction: column; } label { margin-bottom: 10px; font-size: 1em; color: #555; } input[type="number"] { padding: 10px; margin: 5px 0 15px; border: 1px solid #ddd; border-radius: 4px; font-size: 1em; } button { background-color: #4CAF50; color: white; padding: 10px 15px; border: none; border-radius: 4px; font-size: 1em; cursor: pointer; transition: background-color 0.3s ease; } button:hover { background-color: #45a049; } p { font-size: 1.1em; font-weight: bold; color: #333; } .error { color: #ff4444; } .result { color: #4CAF50; } </style> <div class="container"> <h2>Калькулятор индекса массы тела (ИМТ)</h2> <form method="post"> <label>Вес (кг): <input type="number" name="weight" step="0.1" required max="500"></label> <label>Рост (см): <input type="number" name="height" step="0.1" required max="300"></label> <button type="submit">Рассчитать</button> </form> <?php if ($result): ?> <p class="<?= strpos($result, 'Введите') !== false ? 'error' : 'result' ?>"><?= htmlspecialchars($result, ENT_QUOTES, 'UTF-8') ?></p> <?php endif; ?> </div> Это рабочий прототип — онлайн-калькулятора ИМТ (индекса массы тела), Что делает этот калькулятор? Принимает ввод пользователя: вес и рост; Валидирует данные (в диапазоне, в нужном формате); Выполняет арифметический расчёт; Отображает результат на той же странице, без редиректа; Показывает статус ИМТ (недовес, норма, избыточный вес, ожирение). Это не статическая страница, а динамический компонент, реализованный на PHP и HTML/CSS. Признаки веб-приложения в примере Признак Наличие в проекте Обработка пользовательского ввода ✅ Да Валидация и логика на сервере ✅ Да Динамический вывод результата ✅ Да Интерактивное поведение страницы ✅ В рамках форм Отображение бизнес-логики (расчёт) ✅ Да Таким образом, мы делаем вывод — это веб-приложение, хоть и минималистичное. Почему это веб-приложение, даже если оно маленькое? Веб-приложение — это не обязательно что-то большое, сложное или использующее десятки фреймворков. Это любой веб-интерфейс, реализующий: вычисления, взаимодействие, принятие и обработку ввода от пользователя, возвращение результата, отличающегося от стандартного «статического контента». И наш пример с ИМТ попадает под это определение. Отличие от обычного веб-сайта Если бы по адресу /imt/ просто находился текст вида: …это был бы информационный сайт. Но мы создали интерактивный интерфейс, который делает расчёты на сервере. Следовательно — это уже динамическое веб-приложение, пусть и без использования JavaScript-фреймворков или SPA-моделей.

I. Предварительные замечания 2 февраля 2022 года пользователи форумной платформы MyArena столкнулись с внезапной недоступностью ресурса. Как стало известно из открытых обсуждений, в том числе из темы на IP-Gamers.NET, форум перестал отвечать, одновременно с ним недоступной оказалась и Wiki-система. Позднее появилось краткое уведомление об аварийных работах на сервере баз данных db4.myarena.ru. Событие не сопровождалось подробным техническим разбором со стороны хостинг-провайдера, что затрудняет реконструкцию полной картины, однако позволяет рассматривать данный инцидент как проявление более общей проблемы — отсутствия устойчивой модели прозрачности и коммуникации в централизованных хостинговых структурах. II. Хронология наблюдаемых событий На основе сведений, зафиксированных в пользовательских сообществах, можно выделить следующие ключевые моменты: 02.02.2022, 18:45 (MSK😞 возникли технические неполадки на MySQL-сервере db4.myarena.ru. 19:30 того же дня: сервер, по заявлению MyArena, был восстановлен, однако форум продолжал оставаться недоступным. Позже: пользователи фиксируют массовый спам, указывающий на возможные проблемы с откатом данных или уязвимостями защиты. Актуальное состояние: форум MyArena исчез из публичной навигации сайта, ссылки на него с главной страницы убраны, Wiki по-прежнему не функционирует. Официальные заявления по факту отсутствуют. III. Архитектура и централизованные риски Инфраструктурно MyArena, по-видимому, использует модель централизованного хранения баз данных, разделённого по серверным узлам (db1, db2, db3 и т.д.). Такая архитектура создаёт точку отказа: при сбое одного узла — страдает вся связанная с ним клиентская база. Отсутствие механизма активного резервного переключения (failover), открытого статуса-информирования (status page) и документированных процедур восстановления делает невозможной как диагностику, так и прогнозирование последствий сбоев. Инцидент с db4.myarena.ru подчёркивает слабые места архитектуры: Уязвимость к одиночным сбоям без внешнего оповещения; Зависимость клиентов от внутреннего расписания работ провайдера; Проблемы с изоляцией пользовательских ресурсов в рамках общего кластера. IV. Коммуникационная модель Как справедливо подчёркивается в теме на IP-Gamers.NET, не только технический сбой, но и форма реакции на него со стороны провайдера вызывает вопросы. В частности: отсутствует официальный отчёт об инциденте; исчезновение ссылок на форум сопровождается молчанием; техническая поддержка ограничивается общей фразой "всё в порядке". В модели устойчивой ИТ-инфраструктуры такого рода подход не соответствует современным требованиям к открытости. Пользователь, доверяющий провайдеру свои данные, ожидает не просто технической поддержки, но и полноценной информационной ответственности. V. Цифровая амнезия и потеря контекста Следует подчеркнуть, что потеря форума — это не просто временный технический сбой. Это утрата социального и информационного контекста. В условиях, когда форум используется как платформа для накопления коллективного знания, технической поддержки, истории и обратной связи, его исчезновение представляет собой форму цифровой амнезии. Особенно это критично для сообществ, где форум является основным носителем "социальной памяти": игровых, фанатских, технических. Потеря таких данных может быть эквивалентна разрушению архива или библиотеки. VI. Заключение Инцидент с MyArena — симптоматичное событие. Оно высвечивает системные уязвимости в централизованных хостинг-моделях и требует переосмысления как архитектурных, так и организационных подходов к предоставлению IT-услуг. Точка зрения сообщества, зафиксированная в теме IP-Gamers.NET, в этом контексте особенно важна: она отражает реальную реакцию пользователей, лишённых доступа к своим данным и коммуникационным каналам. В будущем необходим переход от удобных моделей к устойчивым — с возможностью внешнего аудита, резервного копирования, открытой документации и права пользователей на информацию.

Описание проблемы В дефолтной теме MATERIAL Admin - SourceBans++, также известной как new_box, существует неприятный баг: в комментариях к банам вместо Steam-аватара администратора отображается предустановленное изображение по умолчанию. Это визуальное несоответствие ухудшает пользовательский опыт и мешает идентификации администраторов. На основе практического опыта и успешного исправления этой ошибки, публикую подробную инструкцию, которая поможет устранить данную проблему на вашем SourceBans++. ВНИМАНИЕ: Перед выполнением любых изменений обязательно создайте резервную копию файлов. Способ 1: Быстрая замена файла Если вам не требуется вникать в детали и вы уверены в стабильности вашего сервера: Загрузите исправленный файл page_bans.tpl (в данном случае архив уже утерян, поэтому этот способ приведён для полноты картины). Переместите файл в директорию: /sb/themes/new_box/ или для абсолютного пути: /www/z1z.org/sb/themes/new_box/ Перезапустите веб-сервер (если требуется), либо просто обновите страницу в браузере. Способ 2: Ручное редактирование шаблона Если вы, как и автор статьи, предпочитаете контролировать каждый байт и не засорять сервер лишними файлами, выполните следующие шаги: Шаг 1: Открытие нужного файла, Перейдите в директорию темы: /sb/themes/new_box/ или, если используется полный путь: /www/z1z.org/sb/themes/new_box/ Откройте файл page_bans.tpl с помощью текстового редактора, например Notepad++ или любого другого, поддерживающего кодировку UTF-8 и подсветку синтаксиса. Шаг 2: Внесение изменений Перейдите к строке 390 (ориентировочное положение, зависит от версии шаблона). Замените текущий код, связанный с выводом аватара, на следующий: <img src="{$avatar}" width="50" height="50" class="lv-img-sm"> Перейдите к строке 13 (верхняя часть файла). Здесь тоже замените блок отображения аватара на: <img src="{$avatar}" width="50" height="50" /> Шаг 3: Проверка результата Сохраните файл. Очистите кэш браузера (в некоторых случаях также может потребоваться очистка кэша шаблонов, если она включена). Перейдите в раздел банов, откройте комментарии — теперь вместо аватарки по умолчанию должен корректно отображаться Steam-аватар администратора. Заключение Проблема, к сожалению, типичная для тем, основанных на MATERIAL Admin - SourceBans++, особенно в версиях до 1.1.5.4. Если вы используете более старую или модифицированную версию, структура шаблона может отличаться — ориентируйтесь по содержанию и логике шаблона. Отдельное внимание: в случае отката или ошибок — возвращайтесь к резервной копии. Источник Подробности обсуждения и оригинальная публикация находятся на форуме IP-Gamers.NET: https://ip-gamers.net/topic/66-v-kommentarijah-k-banam-v-material-admin-sourcebans-ne-otobrazhajutsja-avatarki

Здравствуйте! Вы получили задание создать веб-приложение с использованием нескольких фреймворков и технологий. Основой должно служить отображение актуальной информации о здоровье, получаемой через HHS API (U.S. Department of Health & Human Services). Возникает вполне уместный и логичный вопрос: Раз приложение отображает данные из API, не является ли оно просто веб-сайтом? В чём вообще разница между веб-приложением и обычным сайтом? 1. Веб-сайт и веб-приложение: ключевые различия Критерий Веб-сайт Веб-приложение Основное назначение Отображение информации Взаимодействие с пользователем Тип данных Чаще статичные (HTML, CMS) Динамичные, с реакцией на действия пользователя Логика на клиенте Минимальная Развитая, на JavaScript-фреймворках Пример Блог, справочный сайт Онлайн-калькулятор, чат, CRM Использование БД Необязательно Почти всегда присутствует Ключевой критерий: Веб-приложение предполагает активное взаимодействие пользователя с интерфейсом, динамическую обработку данных и бизнес-логику. Веб-сайт — это в первую очередь про предоставление информации. Данное различие подробно рассмотрено в этой теме на IP-Gamers.NET, где подчёркивается историческая эволюция: от статичных сайтов Web 1.0 к интерактивным системам Web 2.0 и далее. 2. Использование HHS API: сайт или приложение? HHS API — это набор открытых API. Они позволяют получить данные по темам: Заболеваемость Медицинские учреждения Профилактика и вакцинация Доступ к медицинским услугам Надеюсь на нашем родном Госвеб рано или поздно введут такой сервис как предоставление API. Само по себе отображение этих данных на странице делает ваш проект информационным. Но если вы реализуете: выбор региона, поиск по ключевым словам, динамическую фильтрацию, возможность сохранить результаты или историю, то это уже функционал веб-приложения. Примеры: Сценарий Тип Статическое отображение списка клиник из API Веб-сайт Пользователь выбирает фильтры, сортирует, добавляет в избранное Веб-приложение 3. Архитектура веб-приложения: практический план Ваш проект должен продемонстрировать использование разных технологий и фреймворков. Это типичное учебное или практическое задание, целью которого является отработка взаимодействия компонентов. Базовая архитектура: 1. Frontend: Фреймворк: React, Vue или Svelte Динамическая загрузка данных из API Обработка пользовательского ввода (поиск, фильтры, сортировка) UI-компоненты: карточки, списки, кнопки, формы 2. Backend: Node.js + Express / PHP / Python Flask API-прокси (кэширование, фильтрация, трансформация данных) Контроль доступа (если требуется) 3. База данных (опционально): MySQL / PostgreSQL / MongoDB Хранение пользовательской истории, избранных клиник и предпочтений 4. Дополнительно: Авторизация через Yandex / email Админ-панель для управления контентом (например, через Strapi или кастомный CRUD) Логирование обращений к API 4. Мини-проект: пример реализации Название: HealthInfo Finder Функции: Поиск клиник по городу или области Сортировка по типу услуги или рейтингу Сохранение избранного Авторизация для персонализации Стек: Frontend: React (с Axios для API-запросов) Backend: Node.js (Express-прокси для HHS API) БД: SQLite (для демонстрации хранения) Функционал фронтенда: Компоненты: <SearchBox />, <ClinicList />, <Favorites /> Работа с REST API Обработка загрузки, ошибок, состояния пустого результата 5. Советы по реализации Начните с проектирования интерфейса (прототип в Figma или схематично на бумаге). Составьте список компонентов и API-запросов. Реализуйте сначала минимально жизнеспособную версию (MVP). Постепенно добавляйте интерактивность, хранилище, улучшения UI/UX. Вывод Вы работаете над веб-приложением, если ваш проект: реагирует на действия пользователя; обновляет интерфейс без полной перезагрузки; использует данные из API динамически; содержит бизнес-логику или хранение состояния на клиенте или сервере. Если же ваш проект просто отображает неизменяемую информацию, полученную от HHS API — это информационный веб-сайт.