Репозиторий WordPress заблокировал мои плагины

Да, репозиторий WordPress заблокировал мои плагины... Два из трёх. 

В самом репозитории это выглядело так:

Была отключена возможность скачивания плагинов и их установки. Ну, а я получил соответствующие письма по каждому заблокированному плагину: ark-wysiwyg-comment-editor (визуальный редактор комментариев) и ARK Related Posts (связанные записи).

Честно говоря, я не собирался эти плагины как-то развивать или что-то в них менять - работают и работают. В том числе и на моём блоге. Лишь изредка менял информацию о совместимости с очередной новой версией WordPress. Более того, я вообще отошёл от темы создания плагинов; было увлечение, да прошло. Времени нет и желания. У меня даже минимального набора программ (для локализации плагина и его выгрузки в репозиторий) не осталось. К тому-же и сам процесс этих операций уже подзабыл.

Поэтому, получив уведомление, что репозиторий WordPress заблокировал мои плагины, я особо и не расстроился: всему приходит конец. Видимо и время моих плагинов прошло. Однако неприятный осадок остался...

Почему репозиторий WordPress заблокировал мои плагины

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

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

Конечно, многие плагины создают профессиональные разработчики, причём зачастую это командная разработка, например Yoast, Clearfy и многие другие... Естественно, что такие разработчики всегда в тренде всех изменений и новшеств.

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

ark-wysiwyg-comment-editor (визуальный редактор комментариев)

Это был мой любимый плагин, предмет, если можно так сказать, моей гордости... Поэтому письмо от «инквизиции» по поводу него я открыл в первую очередь. Что от меня требовалось:

To help restore your plugin as quickly as possible, you are required to do the following:

1. Review the report (listed below) and make corrections to prevent it from being exploitable
2. Perform a full security and standards review on your own code
3. Increase the plugin version
4. Ensure the 'tested up to' version in your readme is the latest release of WordPress
5. Update the code in SVN
6. Reply to this email and request a re-review

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

Со своим скудным знанием английского языка, плюс онлайн-переводчики, я понял основную претензию - плагин позволяет вставку iframe, а это даёт возможность внедрения вредоносного кода... Немного поразмыслив, я согласился и отключил эту кнопку в плагине. Вернее сделал так, что выбор этой опции на самом деле её не включал. Ответил на письмо, с указанием своих исправлений... И тут началось...

Я получил ответ, что плагин ещё небезопасен и основным требованием (сразу переведу на русский):

Data Must be Sanitized, Escaped, and Validated.

Когда вы включаете в плагин вызовы POST / GET / REQUEST / FILE, важно дезинфицировать, проверять и экранировать их. Цель здесь - предотвратить случайную отправку пользователем мусорных данных через систему, а также защитить их от потенциальных проблем с безопасностью.
SANITIZE: данные, которые вводятся (пользователем или автоматически), должны быть обработаны как можно скорее. Это снижает вероятность XSS-уязвимостей и MITM-атак, при которых опубликованные данные искажаются.

VALIDATE: все данные должны быть проверены, несмотря ни на что. Даже когда вы дезинфицируете,
помните, что вы не хотите, чтобы кто-то вставлял слово «собака», когда единственными допустимыми значениями являются числа.

ESCAPE: данные, которые выводятся, должны быть экранированы должным образом, когда они выводятся эхом, чтобы они не могли захватить экраны администратора. Есть много функций esc _ * (), которые вы можете использовать, чтобы убедиться, что вы не показываете людям неправильные данные.

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

Скажу только одно: что бы я ни делал, всегда получал ответ начинающийся фразой: Your plugin cannot be reopened yet.

Тогда я решил оставить визуальный редактор комментариев в покое, что второй заблокированный плагин (связанные записи) немного попроще и спасти хотя-бы его...

ARK Related Posts (связанные записи)

Здесь была всё та-же картина. Я читал документацию по ссылкам в письмах «Инквизиции», а также сопутствующую документацию по PHP, в частности по требуемым операторам, вносил изменения, обновлял плагин, отвечал на письма, но ответ всегда был неутешителен: You are required to sanitize and escape...

Иногда мне казалось, что я уже разобрался в сути применения sanitize() и esc(), потратив кучу времени я привёл необходимые строки кода примерно вот к такому виду:

'btn_undo' => esc_html(sanitize_text_field($_POST['btn_undo'])),

Вот вам, запрос и санирован, и экранирован. Но это оказалось неверным подходом. И разработчики разъясняли мне, что санировать и экранировать одновременно не нужно. Это приведёт к неоправданным потерям ресурсов и замедлит работу. В каждом конкретном случае нужен какой-то один оператор. Поясняли и разницу между этими случаями. А так-же и то, что в плагине у меня иногда повторно применяется санирование, этого не нужно...

В общей сложности мы с разработчиками обменялись 10-ю письмами, пока я, наконец, сделал всё правильно. И вот настал долгожданный момент: Your plugin has been re-listed in the directory. Плагин снова открыт и доступен! Правда, была оговорка, что, мол, мы , как и вы, люди и могли что-то упустить. Поэтому, если в течение последующих 60-ти дней мы обнаружим ещё какие-то проблемы с безопасностью, то мы НЕ БУДЕМ закрывать ваш плагин, но сообщим вам. А вы должны срочно это исправить. Если-же проигнорируете такое письмо, то вот тогда плагин будет закрыт....

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

И опять визуальный редактор комментариев

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

Теперь работа пошла быстрее, я уже понимал что и зачем делаю и вот я отправляю очередное письмо разработчикам WordPress - проверьте, мол, всё исправил...

Однако, вопреки моим ожиданиям, получил отрицательный ответ. Теперь «Инквизиция» зацепилась за то, что плагин использует CDN-версии редакторов и потребовала включить редакторы в плагин локально. Что такое CDN можно посмотреть здесь.

Поскольку CDN - это всё-таки сервисы скоростной доставки контента, а наши хостинги у всех разные, особенно в плане загрузки скриптов и т.д., то плагин был изначально ориентирован именно на CDN. И я начал спорить с разработчиками WordPress, отстаивая свою точку зрения. Но «Инквизиция» не прониклась моими аргументами: - ты грешен, покайся перед сожжением на костре... Не помогло даже то, что, например, TinyMCE теперь требует API-Key от каждого пользователя, а в моём варианте ничего этого не нужно!

По итогу пришлось уступить, тем более, что они мне прислали ссылку на тот-же TinyMCE, не требующий никаких API... И я вынужден был заняться комплектацией обоих редакторов (TinyMCE и CkEditor) всеми необходимыми модулями, которые раньше находились на стороне CDN-версий и не утяжеляли плагин. Сделал. Загрузил. Отправил письмо - вот, будь по вашему, разблокируйте уже плагин.

Но не тут-то было! Теперь от меня стали требовать использовать nonce.

nonce

Однократно используемое число (от англ. nonce — «number that can only be used once» — число, которое может быть использовано один раз) в криптографии — одноразовый код, выбранный случайным или псевдослучайным образом, который используется для безопасной передачи основного пароля, предотвращая атаку повторного воспроизведения. В отличие от случайных чисел, здесь не требуется непредсказуемости числа, достаточно неповторяемости.

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

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

Репозиторий WordPress заблокировал мои плагины - что в итоге?

В итоге, все мои плагины снова доступны в репозитории WordPress. Правда, по тем, что были заблокированы, сильно просела статистика установок. Так, например, визуальный редактор комментариев до блокировки показывал более 4500 активных установок, а теперь только 1000. Но это для меня не столь важно, тем более, что в письме об открытии плагина было сказано: «В ближайшее время вы можете заметить, что ваша статистика не синхронизирована. Поскольку наши системы сильно кэшированы, это может занять некоторое время, чтобы все серверы и API-интерфейсы наверстали упущенное. Пожалуйста, не паникуйте. Они будут правильно сброшены через достаточно времени, и мы ничего не можем сделать, чтобы это ускорить.».

Гораздо важнее то, что моя первоначальная версия плагина с использованием CDN мне нравилась куда больше. И работало всё, по-моему, быстрее. Но тут я ничего уже не могу поделать...

К тому же, как оказалось, под учёткой администратора я вижу под статьёй CkEditor, а другие не видят. В то-же время TinyMCE виден всем. Хорошо, что мне об этом написали читатели... Пришлось долго разбираться и с этим. Как оказалось, дело в скрипте. У TinyMCE файл скрипта называется tinymce.min.js, а у CkEditor - ckeditor.js...

TinyMCE спасала вот эта «min» в имени файла, насколько я понял. А вот скрипт CkEditor, без этой вставочки, кешировался плагином Clearfy, причём только если это не администратор. Из-за этого искажалась ссылка на редактор и он не работал. Пришлось в Clearfy отключить кэширование и минимизацию скриптов. Но пока я нашёл причину... Лучше об этом не рассказывать...

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

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

Ну, а мои плагины доступны, как и прежде.

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

Материалы по теме:

Работа над блогом

Плагин комментариев для WordPress

Еще один плагин заглох… MCEComments

Надо ли устанавливать обновления WordPress

Закрыть ссылки в комментариях WordPress

Почему я удалил CommentLuv