Да, мне она кажется в этой ситуации самой правильной, так как ограничения топиков по времени, или другие изменения в логике добавления постов так же ущемляют права пользователей сайта а это будет влиять и на посещаемость и на развитие проекта в целом.
У меня было что то подобное, пока не решил проблему с закрытием этой уязвимости но думаю нужно думать о вставки captcha при добавлении топиков и блогов.
За время атаки было создано 1948 топиков
А с этим разобрался очень просто у меня 2 пользователя за неделю добавили около 800 топиков, удалив пользователей через DB (базу данных) при этом почистились и топики и другие данные связанные с этими пользователями. Но помните чистка всех связанных данных произойдёт если у Вас тип таблицы InnoDB
Некоторые конфигурации должны меняться в зависимости от домена, вот эти.
/**
* Настройки HTML вида
*/
$config['view']['skin'] = 'synio'; // шаблон(скин)
$config['view']['name'] = 'Your Site'; // название сайта
$config['view']['description'] = 'Description your site'; // seo description
$config['view']['keywords'] = 'site, google, internet'; // seo keywords
$config['view']['tinymce'] = false; // использовать или нет визуальный редактор TinyMCE
$config['view']['noindex'] = true; // "прятать" или нет ссылки от поисковиков, оборачивая их в тег <noindex> и добавляя rel="nofollow"
$config['view']['img_resize_width'] = 570; // до какого размера в пикселях ужимать картинку по щирине при загрузки её в топики и комменты
$config['view']['img_max_width'] = 5000; // максимальная ширина загружаемых изображений в пикселях
$config['view']['img_max_height'] = 5000; // максимальная высота загружаемых изображений в пикселях
$config['view']['img_max_size_url'] = 500; // максимальный размер картинки в kB для загрузки по URL
$config['view']['no_assign'] = array('db'); // список групп конфигурации, которые необходимо исключить из передачи во Viewer. Только для системного пользования.
/**
* Настройка путей
* Если необходимо установить движек в директорию(не корень сайта) то следует сделать так:
* $config['path']['root']['web'] = 'http://'.$_SERVER['HTTP_HOST'].'/subdir';
* $config['path']['root']['server'] = $_SERVER['DOCUMENT_ROOT'].'/subdir';
* и возможно придёться увеличить значение $config['path']['offset_request_url'] на число вложенных директорий,
* например, для директории первой вложенности www.site.ru/livestreet/ поставить значение равное 1
*/
$config['path']['root']['web'] = 'http://'.$_SERVER['HTTP_HOST']; // полный WEB адрес сайта
/**
* Настройка базы данных
*/
$config['db']['params']['host'] = 'localhost';
$config['db']['params']['port'] = '3306';
$config['db']['params']['user'] = 'root';
$config['db']['params']['pass'] = '';
$config['db']['params']['type'] = 'mysql';
$config['db']['params']['dbname'] = 'social';
$config['db']['table']['prefix'] = 'prefix_';
$config['path']['uploads']['root'] = '/uploads'; // директория для загрузки файлов
так же не помешало бы сделать допустим папку upload/ подменять на upload/domeins_com это можно и не делать и всё будет храниться в upload/ но если Вам понадобится когда нибудь отделить один из доменов, а это наверняка будет и вот здесь будет много сложностей и проблем.
Первое наверное некоторые конфигурации должны меняться в зависимости от домена. Второе это конечно же вывод контента топиков и блогов в зависимости от домена.
Плюсы тоже есть, можно организовать единую базу пользователей и их единая авторизация на этих сайтах.:)
Но есть и опасность что если контент будет повторяться твои все сайты забанят как зеркала..:(
А при чём здесь convert_1.0.3_to_alto.sql здесь именно не меняется prefix_ при создании новых таблиц в DB…
Получается что в config добавляется новый префикс а в таблице остаётся prefix_
Это реализуется созданием базы тегов и из неё уже делается автокомплит тегов, а потом при добавлении или редактировании делаете проверку есть ли такой тег в этой базе или нет… У меня была подобная реализация но не для тегов а для фильмов
суть такая что при создании топика можно указать фильмы которые в этом топики присутствуют, а возможно добавить фильм только при условии что этот фильм есть в базе..:)
Не понимаю для чего на чистом сайте открывать закрытую регистрацию, тем более на 24 часа..:) Если на сайте нету пользователей которые могут отослать инвайт то как же у Вас зарегистрируются..?
Мне кажется инвайты нужно использовать когда у Вас активных пользователей 1000+ и при том которые в этом сообществе как минимум делают посты и хотят его развивать…
Вообще да, править ядро очень плохо, НО я даже за такое решение так-как здесь описан полное пошаговое руководство которое можно реализовать не только для топиков в ядре но и у своих плагинов или модулей, у которых бы хотелось видеть Яндекс или Google карты..:)
В некоторых случаях это не помогает, так-как в место site.ru некоторые используют www.site.ru но это пол дела, а в случае субдоменов не используя эту конструкцию
А с этим разобрался очень просто у меня 2 пользователя за неделю добавили около 800 топиков, удалив пользователей через DB (базу данных) при этом почистились и топики и другие данные связанные с этими пользователями.
Но помните чистка всех связанных данных произойдёт если у Вас тип таблицы InnoDB
groups.devls.ru
так же не помешало бы сделать допустим папку upload/ подменять на upload/domeins_com это можно и не делать и всё будет храниться в upload/ но если Вам понадобится когда нибудь отделить один из доменов, а это наверняка будет и вот здесь будет много сложностей и проблем.
Второе это конечно же вывод контента топиков и блогов в зависимости от домена.
Плюсы тоже есть, можно организовать единую базу пользователей и их единая авторизация на этих сайтах.:)
Но есть и опасность что если контент будет повторяться твои все сайты забанят как зеркала..:(
Получается что в config добавляется новый префикс а в таблице остаётся prefix_
Мне кажется инвайты нужно использовать когда у Вас активных пользователей 1000+ и при том которые в этом сообществе как минимум делают посты и хотят его развивать…
Единственное почему бы просто в место
вставить