Yuki

23 марта 2023

Спасибо большое за направление )) без него бы наверное еще не скоро бы сделал, а так за часок справился ))

Если кому-то понадобиться, то получилось что-то такое:

<?
define ( 'DATALIFEENGINE', true );
define ( 'ROOT_DIR', dirname(dirname(__FILE__)) );
define ( 'ENGINE_DIR', ROOT_DIR . '' );

include(ENGINE_DIR . '/data/config.php'); // получаю переменную $config
include_once ENGINE_DIR . '/classes/plugins.class.php'; // для DLEPlugins

switch ($config['cache_type']) {
  case '1':
    include_once (DLEPlugins::Check(ENGINE_DIR . '/classes/memcache.class.php')); // получаю класс dle_fastcache
    a0_clear_all($config);
    break;
  case '2':
    include_once (DLEPlugins::Check(ENGINE_DIR . '/classes/redis.class.php')); // получаю класс dle_fastcache
    a0_clear_all($config);
    break;
  
  default: // если файловый кеш
    include_once(DLEPlugins::Check(ENGINE_DIR . '/inc/include/functions.inc.php'));
    clear_all_caches(); // удаление файлов с диска
    clear_static_cache_id();
    break;
}

function a0_clear_all($config) { // очистка кеша из памяти
  $dlefastcache = new dle_fastcache($config);
  $dlefastcache->clear();
}


var_dump('END');

Из минусов такого подхода: кеш удаляется полностью вся (может для кого-то и не минус).

22 марта 2023

Исходник: сайт с включенным кешированием через Memcache или Redis (это важно!), так же включено кеширование счётчика (не проверял этот пункт).

Действия: заходим на главную страницу и запоминаем название публикации, потом заходим напрямую в БД и меняем title той публикации. Возвращаемся на главную страницу и обновляем её. Мы видим старое название, всё правильно, оно закешировалось, так и должно работать! На всякий случай идём в админку, жмём кнопку "Очистить кеш", проверяем главную страницу и видим изменённое название, всё хорошо, повторяем начальные действия, но кеш не очищаем! Далее...

Рассмотрим несколько ситуация.

1. Прямое удаление файла.

Заходим в папку "engine\cache\system" и удаляем там файл "cron.php" (с другими файлами такое не работает).

Результат: мы видим изменённое название (которое меняли напрямую в БД), т.е. кеш сбрасывается(или просто сгенерировался новый) и на главной странице и в FullStory. Так и должно быть?

2. Запуск очистки кеша сторонним скриптом.

Заходим в админку, и смотрим как вызывается кнопка "Очистить кеш", видим что-то такое: "engine/ajax/controller.php?mod=adminfunction&action=clearcache&user_hash={$dle_login_hash}" сходили посмотрели и понимаешь, что вызывается функция очистки кеша из файла "/inc/include/functions.inc.php", а именно "clear_all_caches()" всё понятно, пробуем эмулировать в стороннем php скрипте.

Пишем код в папке движка в левом файле:

<?
define ( 'DATALIFEENGINE', true );
define ( 'ROOT_DIR', dirname(dirname(__FILE__)) );
define ( 'ENGINE_DIR', ROOT_DIR . '' );

include_once ENGINE_DIR . '/classes/plugins.class.php';
include_once(DLEPlugins::Check(ENGINE_DIR . '/inc/include/functions.inc.php'));

clear_all_caches(); // Удаляет файлы из папки кеша, вызывает clear_cache() и возможно opcache_reset()
clear_static_cache_id(); // генерирует 5ти значную строку

// @unlink( ENGINE_DIR . "/cache/system/cron.php" ); // если добавить эту строку то будет норм, но мне не понятен механизм, связанный с удалением этого файла


var_dump('END');

Результат: все файлы из папки "engine\cache\system" удаляются успешно (кроме cron.php, по условию функции и не должен), казалось бы всё хорошо, бежим на главную страницу, обновляем и видим какие-то странные дела, название не изменилось, хоть и должно было подгрузиться новое из БД

3. Запуск через $dle_api.

Ну всё хватит, повозились с движком и пошли читать документацию. Находим в документации API и как раз нужная для нас функция "clean_cache()". Пишем небольшой php скрипт в папке engine (или где угодно по сути)

<?
define ( 'DATALIFEENGINE', true );
define ( 'ROOT_DIR', dirname(dirname(__FILE__)) );
define ( 'ENGINE_DIR', ROOT_DIR . '' );

include(ENGINE_DIR . '/api/api.class.php');

$dle_api->clean_cache();

var_dump('END');

Результат: видим в консоли надпись "END" скрипт отработал успешно, НО, название публикации без изменений, в том числе не удалился ни один файл из папки "engine\cache\system". Есть ощущение, что api работает(~~если вообще работает~~) только если переключить режим кеширования на "Файловый".

PS: Скрипты запускались через консоль командами "php file_name.php" (по умолчанию версия 8.1.9) и "/php/PHP_7.4/php.exe file_name.php" (версия 7.4.30)

PS2: В основном для тестов использовал из консоли версию 7.4, т.к. 8.1 выдавала ошибки типа "Deprecated", к примеру:

Скрытый текст

Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in \engine\inc\include\functions.inc.php on line 24

Deprecated: ip2long(): Passing null to parameter #1 ($ip) of type string is deprecated in \engine\inc\include\functions.inc.php on line 38

Warning: Undefined array key "HTTP_HOST" in \engine\inc\include\functions.inc.php on line 38

Warning: Attempt to read property "connection" on null in \engine\inc\include\functions.inc.php on line 1127

PS3: Еще заметил одну и ту же функцию в двух разных файлах, с один лишь отличием, одна из них всегда возвращает true. Файл "engine\inc\include\functions.inc.php" строка 1123 функция function clear_cache($cache_areas = false) и файл "engine\modules\functions.php" строка 909 та же функция "function clear_cache($cache_areas = false)". Думается мне писать одно и то же не очень.

И самое важно, ради чего всё это! Пожалуйста помогите, как очистить кеш через сторонний скрипт?

22 марта 2023

Сделал в общем так:

Установил npm пакет "exec-php" в nodejs, и запускаю через него php функцию api (см. документацию)

$dle_api->external_auth($login, $password)

И в зависимости от ответа true/false принимаю действия.

6 марта 2023

Входные данные:
1. Сайт на DLE
2. Чат на Vue 3 + Node.js + MySQL. Дополнение в виде чата. Чат могут видеть только авторизованные пользователи на самом сайте. Проверка такая:

[not-group=5]
{include file="vChat/dist/index.tpl"} // тут как раз подключается vue.js
[/not-group]

Вопрос: Как определить какой именно пользователь отправил сообщение в чате, если чат и сайт связаны только одно БД и в чате нет авторизации?

Вариант реализации придумал пока только один:

Отправлять в POST запросе `user.id` и сравнивать его значение с БД + что бы определить, что идентификатор не подменён на фейковый делать проверку `user.ip` (есть в БД). На node.js типа: `+response.body.user_id === user.id && req.socket.remoteAddress === user.ip`

Хотелось бы просто предложения услышать, можно ли как-то еще реализовать проверку на то, кто именно отправляет сообщения в чате?

PS: какую схему авторизации вообще использует DLE ?

6 апреля 2013

Спасибо за столь быстрый и внятный ответ (искренне благодарен)!

В таком случае какой форум могли бы порекомендовать? (за исключением IP. Board)

Как относитесь к интеграции форум+сайт, к примеру тот же IP. Board+DLE ?

6 апреля 2013

Нужна помощь и советы.

С данной проблемой сталкиваюсь уже второй раз.

Сайт: http://animefull.ru/

У некоторых пользователей ругается антивирусник Dr.Web на сайт, у самого стоит KIS 13 и кстати он молчит...

В первый раз (это было 2 месяца назад) избавился от этой проблемы простой переустановкой движка, а точнее обновлением с 9,7 до 9,8. В этот раз попробую всё так же сделать, наверняка прокатит. Но вот в чем вопрос:

Вопрос: Как обезопасить себя от повторного появления такой проблемы? Было ли у кого нибудь что-то подобное? Что можете посоветовать?

PS: FTP отключен, включаю его только когда он необходим, хостинг Jino. Проверял файлы по дате изменения, те что изменены недавно, походу чистые (без вредоносного кода). Может проблема с БД ?

Пример:

Войти

Yuki

Публикации

Зарегистрирован

Посещение

Дней в лидерах

Тип публикации

Форум

Сообщения, опубликованные пользователем Yuki

Очистка кеша

Очистка кеша

Как проверить кто отправил сообщение в чате?

Как проверить кто отправил сообщение в чате?

Взлом / Вредоносная программа / Проблемы с кодировкой

Взлом / Вредоносная программа / Проблемы с кодировкой

Форум

Активность