Перейти к содержанию

SoNWarrioR

Пользователи
  • Постов

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

  • Посещение

Сообщения, опубликованные SoNWarrioR

  1. Добавить в .htaccess
    php_value display_errors 1
    php_value display_startup_errors 1
    php_value error_reporting E_ALL 
    

    или/и в index.php 

    ini_set('error_reporting', E_ALL);
    ini_set('display_errors', 1);
    ini_set('display_startup_errors', 1);

    Так же возможно работает херево как раз из-за того, что у вас сохранился кеш днс:

    Цитата

    Для Windows Vista, Windows 7, Windows 10:
    Для этого нажмите меню "Пуск", там в строке Поиска внизу введите слово cmd (английскими буквами) после чего нажмите Enter (если строки поиска нет, то в меню зайдите в Поиск). У Вас найтеся программа cmd, запустите её.

    У вас откроется командная строка Windows. Введите там следующую фразу: ipconfig /flushdns и нажмите Enter (можно скопировать, чтобы не писать руками - тут копируете, в командной строке правой кнопкой мышки вставляете).

     

  2. 15 минут назад, Firuz сказал:

    нет свой

    WOLF, bro свой

    Скиньте пожалуйста скриншот до ошибки и во время ошибки, и желательно скриншот  phpinfo. 

    Так же не помешала бы конфигурация сервера, (Apache, nginx, php-fpm и т.д.)

  3. 20 минут назад, Вячеслав Русаков сказал:

    Приветствую

    Как сделать так, чтобы никто не мог ничего копировать с форума? а то уже достали все мягко говоря.. написал описание для форумов - через пару дней уже на других форумах, сидел потом 5 часов менял, сегодня уже опять под чистую скопировали.. как так можно вообще, а самое смешное, что ТИц форума 90, а при анализе текста указывают какие то нулевые юкозовский сайты, аж не могу уже.. Если нельзя вообщем весь форум запретить копировать, то как хотя бы в темах сделать запрет? заранее спасибо. А то хук не могу найти что-то

    Для этого, например в yandex существует функция в вебмастере "Оригинальные тексты". Нет ни одного средства, которое позволило бы вам защитить сайт от копирования.

  4. 5 часов назад, Snappi сказал:

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

    То что вы видите на гидхабе - это исходники. Собирайте самостоятельно из него плагин.

  5. 1 минуту назад, Snappi сказал:

    Здравствуйте! У меня возникла проблемка с установкой плагина. На GitHub сам плагин без .xml файла для установки. Есть только архив с кучей файлов и папок. Автор плагина сказал, что проверял его на последней версии. Тогда как возможно установить плагин без .xml?  Если надо, могу дать ссылку на GitHub, чтобы вы увидели структуру хука.

    Думаю что у Автора можно было бы тогда и спросить, как его устанавливать. А почему бы сразу не дать ссылку на гидхаб?

  6. 2 часа назад, Envy сказал:

    спасибо, но мне нужна частная группа, а не админ(

    может кто знает, тут вроде много кодеров

    Попробуйте $member->inGroup( 15 )

    Или же in_array( 15 , $member->groups ) 

    Все это возвращает булев тип

    По крайней мере должно -_-

  7. Может быть вообще две вещи
    Первая:
    Требуется в файле .htaccess убрать перенаправленние на https - пример:

    RewriteEngine On
    RewriteCond %{HTTPS} !on
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

    Второе:
    в файле conf_global.php есть строчка 'base_url', там ваш домен по умолчанию. Если стоит https - то поменять на http


     

  8. Посмотрите пожалуйста сначала на дату. Потом на строку. Потом опять на дату. "Да, я на коне". Так вот, скорей всего, то что бы переименовано уже нету, например тема, коммент, обзор, блог, пост, новость, юзер... и тд. и тп.

  9. Знаете, в домах, на щитках обычно висит такая надпись "Не лезь - убьет(на#$й к е#$!м)", но некоторые все равно туда тыкают палочкой... своей... маленькой. Но не в этом суть. Если не знаете, чего же тогда пытаетесь ковырять? Автоматически при установки IPS права выставляет сам. Если Вам требуется что-то модифицировать коль Вам не нравится, то прошу

    Спойлер

    Presuming that a 'web application' runs on a server (like apache, nginx, etc) and is written in some dynamic scripting language (like PHP, Ruby, etc), you have a misunderstanding in who the 'user' is.

    The user is not the person who is logged into your application - that, and their role in the application (admin, etc) is completely irrelevant to the scenario. The user is the linux system user that the process runs under. The code of your website is run as only one user - it may be the user of your webserver (which isn't really a good thing), or it may be a user specific to your site (which is much better).

    On linux, users belong to groups - we can add a user to another group and assign privileges to that group.

    A good setup will have your server run as one user (let's call this user 'webserver') and your dynamic scripting language run (e.g. via FastCGI) as its own user (one user per site - let's call our first user 'site1').

    To serve your files, the webserver needs access to them, and the scripting language needs access to them. That means: 'site1' and 'webserver' need to be able to read your files. Only one of them, however can 'own' the files. The owner is the 'user' (in user, group, other). We also need our scripting language to be able to write to the directory (and read the files it has written). The user 'site1' therefore, needs read and write permissions. Since we want group and other permissions to be as restrictive as possible, our 'owner' will be 'site1', and the corresponding user permissions will be read and write.

    Since we cannot specify the permissions for our webserver as another 'user', we will add 'webserver' to the 'site1' group (you could of course, create a different group with both 'site1' and 'webserver' in it. All members of this group will be given the same permissions. The most lax permissions (of the user, group, other set) will be applied to any given user to determine their permissions.

    It is worth noting that a good setup should not require files to have execute permissions for a dynamic language. The files are not directly run, but rather are read into an interpreter - only read permissions are needed to run a typical script (one that doesn't write anything).

    The 'execute' permission on directories has a different meaning - it permits traversal without being able to read the contents. In order to be able to read a file in a directory, a user must have 'execute' permissions on EVERY directory above it.

    For a web application, every file must have read permissions by its owner - otherwise, it is a fairly pointless file. Whether a user or an admin uploads files (via your web application) the 'owner' (i.e. the dynamic language) needs write permissions. An efficient setup will try to serve static files directly via the web server, as dynamic languages tend to be slow at reading in large files and echoing out the contents. The web server therefore needs read access to your static files.

    Therefore, the minimal file permissions may be:

    • A file in a directory where user uploaded static files (images/swf/js files) will reside: 640
    • A file in a directory where admin uploaded static files (images/swf/js files) will reside: 640
    • A file in a directory where libraries used in the application reside: 400 (or 440)
    • A file in a directory where executable/browsable server side scripts will reside: 400 (or 440)
    • A file in a directory where the already existing files (txt or xml) will be edited by code on server side: 640 or 600
      • (depends on whether the web server will display these, unmodified at times)

    While, the minimal directory permissions may be:

    • A directory where user uploaded static files (images/swf/js files) will reside: 750
    • A directory where admin uploaded static files (images/swf/js files) will reside: 750
    • A directory where libraries used in the application reside: 500 (or 550) [should be 510 at least]
    • A directory where executable/browsable server side scripts will reside: 500 (or 550) [should be 510 at least]
    • A directory where the already existing files (txt or xml) will be edited by code on server side: 750 or 700
      • (depends on whether the web server will serve files from here, unmodified at times)

    Once again - your web server must have 'execute' permissions on every directory above the one it needs access to - so even if the web server won't serve files from a given directory, we should grant it execute permissions.

    It is fairly common to give the web server read access to most of the files (so change those 500 to 550). Default 'somewhat secure' permissions are commonly 755 for directories and 644 for files - no execute permissions, everyone can read, and only the user can write - you will note that the vast majority of files on a linux system have these permissions.

    Keep in mind that the 'other' permissions refer to any system user who is not the owner or in the group (i.e. all remaining system users). Keeping your 'other' permissions restrictive is good, because these users are an unknown - you haven't explicitly given them permission. The other permissions are often the easiest to take advantage of on a compromised system (e.g. one of the reasons why /tmp is a common target).

    In the context of the above, I don't think your last two questions are that relevant. Set your directory permissions to 550 (and file permissions to 440), and then grant the user write permissions for whatever directories your application will be writing to (i.e. directory: 750; file: 640).

    (You will obviously need write permissions to upload the files - but if you wish, you can remove those afterwards - arguably though, if someone is writing to a directory which only the owner can write to - your account has been compromised - which is one of the reasons for keeping restrictive permissions).

    Достаточно интересно рассказано и объяснено. 

  10. Вообще была такая же проблема, конечно чуть по меньше. 600мб достигли, но это за 1,2 недели. В общем трабла была в логах на сайте. Почистил логи в базе по поиску "logs" по всем таблица. На сайте в АЦ в поиске вводите logs и там будет примерно 6 пунктов. Заходите в каждый и в настройках выставляйте например "3 дня" или "1 день", т.к. по умолчанию 30 дней стоит. И например при частых ошибках SQL которые не видны на сайте, но они есть, лог забивается быстро и за 30 дней выходит достаточно много.

  11. Сказал же Вам, заходите в папку где должны лежать файлы, и сами туда льете

    НЕ ЧЕРЕЗ IPS, а САМИ!!! Самому, руками, вот как вы в туалет ходите, вот так же туда и залейте, если не хотите чтобы файлы были битыми. Вы кеш удалили?

  12. к сожалению не могу просматривать ваш форум.

    Попробуйте обновить кеш после заливки новых смайлов.

    Ну или смотрите путь до "смайла" который не отображается и заливайте по этим путям картинки с такими же названиями и разрешениями.

×
×
  • Создать...