Скажите пожалуйста!
Можно ли как нибудь защитить php-й код от посторонних глаз (закодировать или скомпилировать)
А также можно ли что код само уничтожался через какое-то время
Защита скриптов на PHP
Stanislav, можно, только тебе понадобится коммерческая версия PHP от Zend. Там предусмотрена шифрация скрипта на уровне ядра.
Даже самый дурацкий замысел можно воплотить мастерски
2AiK
Честно говоря, ни разу не слышал о таком.... буду знать....
2Stanislav
А я бы прежде всего стал бы заклевать дыры в скрипте (ну если они есть).... Особенно обратить внимание на проверки пост, гет переменных, и ограничить прием "проверяния", только допустим по post-форме, например $GLOBALS['_POST']['variable_name']. При надобности переменные присутствия, например админа, типа $admin_here в самом начале приравнять к false, а уже потом, после авторизации делать true если все хорошо...Отключи обязательно ВСЕ сообщения об ошибках (error_reporting(0)). Кто знает, какой путь высветиться, когда fopen не сможет открыть txt файл с базой админов))). а при таких делах уж и я справлюсь, и расковыряю твою "крепость". Не давай клиенту знать больше о расположении твоих папок и файлов в каталоге сайта. Даже смотри, чтоб картинки не лежали в той же папке, что и основные модули, файлы и прочее...да и гет-запросы к файлам, типа http://site.hrum/script.php лучше исключить,и сделать скрипт обработчик URI, который запускал тот же скрипт, но при получении такого гета: http://site.hrum/?a=2 и никогда не называй "открытые переменные для чужого глаза" важными именами, типа http://site.hrum/?admin_status=0 - первый сигнал к атаке! ну, и надо, чтоб хостеры настроили апач чтоб не было доступа к просмотру папок. И конечно огородись от SQL-инъекции!
после такого и такого никто из вне пальчики пообламывает, в носу ковырять от безнадеги.... а если кто изнутри злобствовать будет, то .мне кажется, от этого и zend не спасет (хотя, могу и ошибаться)
Честно говоря, ни разу не слышал о таком.... буду знать....
2Stanislav
А я бы прежде всего стал бы заклевать дыры в скрипте (ну если они есть).... Особенно обратить внимание на проверки пост, гет переменных, и ограничить прием "проверяния", только допустим по post-форме, например $GLOBALS['_POST']['variable_name']. При надобности переменные присутствия, например админа, типа $admin_here в самом начале приравнять к false, а уже потом, после авторизации делать true если все хорошо...Отключи обязательно ВСЕ сообщения об ошибках (error_reporting(0)). Кто знает, какой путь высветиться, когда fopen не сможет открыть txt файл с базой админов))). а при таких делах уж и я справлюсь, и расковыряю твою "крепость". Не давай клиенту знать больше о расположении твоих папок и файлов в каталоге сайта. Даже смотри, чтоб картинки не лежали в той же папке, что и основные модули, файлы и прочее...да и гет-запросы к файлам, типа http://site.hrum/script.php лучше исключить,и сделать скрипт обработчик URI, который запускал тот же скрипт, но при получении такого гета: http://site.hrum/?a=2 и никогда не называй "открытые переменные для чужого глаза" важными именами, типа http://site.hrum/?admin_status=0 - первый сигнал к атаке! ну, и надо, чтоб хостеры настроили апач чтоб не было доступа к просмотру папок. И конечно огородись от SQL-инъекции!
после такого и такого никто из вне пальчики пообламывает, в носу ковырять от безнадеги.... а если кто изнутри злобствовать будет, то .мне кажется, от этого и zend не спасет (хотя, могу и ошибаться)