Всем доброго времени суток!
Не знаю, куда правильнее адресовать данный вопрос, но он касается безопасности. Безопасности нас нас как подрядчиков.
Суть вопроса: я не очень уверен в заказчике, поэтому мне нужно какое-то решение для подстраховки, а именно что-то (какой-то код) который бы, например, ставил заглушку на сайт или что-то портил.
Конечно, логично было бы не отдавать сайт клиенту, но это уже произошло. Сайт на его хостинге и там делаются бекапы. Поэтому, как я считаю, логичнее было бы подсунуть в код ежа, который бы со временем тоже сохранился в бекапах и отрубал бы сайт при необходимости. Мне нужна сама концепция. Еще момент, что у клиента есть штатный программер. Поэтому нужно что-то похитрее.
Заранее благодарю.
Полная Версия: Защита от недобросовестного заказчика.
| Цитата (kit @ 30.06.2014 - 10:11) |
| Еще момент, что у клиента есть штатный программер. Поэтому нужно что-то похитрее. |
Против этого аргумента ничего не поможет
Можно только заранее, на этапе подписания договора, предусмотреть всё. Предоплаты, выплаты за каждый этап из оговоренных, показ сайта на своем хостинге. И - обязательное подписание договора!!!
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
Ну разве что сделать полную обфускацию и кодирование всего исходного кода вещами вроде Zend Guard или IonCube. 2005 гарантии тоже не дают, но задачу усложнят.
_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
Знаю 2 варианта "привязать" проект к себе.
1-й вариант - оставить себе в коде бекдоры. Чем лучше они спрятаны и чем больше их понатыкано в разных местах, тем больше шансов, что все не найдут.
Подразновидность - бекдор наизнанку. Движок делается таким, чтобы медленно (несколько недель или месяцев) сам по себе умирал, и недокументированная функция для реанимации. Пока раз в месяц заходишь по недокументированному адресу и реанимируешь движок, он работает как заза; а начал заказчик хамить - перестал заходить и движок медленно умирает. А ты, как разработчик, по зову быстро починишь.
2-й вариант - какую-то жизненно-важную функцию выполнять на своем сервере. Например, шифрование паролей пользователей. Захотят свалить, отключишь шифрование на своей стороне, и даже если другой программист напишет новый алгоритм авторизации, старую базу пользователей они потеряют...
_____________
Бесплатному сыру в дырки не заглядывают...
1-й вариант - оставить себе в коде бекдоры. Чем лучше они спрятаны и чем больше их понатыкано в разных местах, тем больше шансов, что все не найдут.
Подразновидность - бекдор наизнанку. Движок делается таким, чтобы медленно (несколько недель или месяцев) сам по себе умирал, и недокументированная функция для реанимации. Пока раз в месяц заходишь по недокументированному адресу и реанимируешь движок, он работает как заза; а начал заказчик хамить - перестал заходить и движок медленно умирает. А ты, как разработчик, по зову быстро починишь.
2-й вариант - какую-то жизненно-важную функцию выполнять на своем сервере. Например, шифрование паролей пользователей. Захотят свалить, отключишь шифрование на своей стороне, и даже если другой программист напишет новый алгоритм авторизации, старую базу пользователей они потеряют...
_____________
Бесплатному сыру в дырки не заглядывают...
Ничего так не укрепляет веру в человека, как предоплата. А то, что вы предлагаете, Михаил - наказуемо.
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
_____________
Свои мозги еще никто не отменял.
Телепатов нету.
| Цитата (waldicom @ 30.06.2014 - 18:54) |
| Ничего так не укрепляет веру в человека, как предоплата. |
Если проект подразумевает полную сдачу заказчику - конечно предоплата или поэтапная оплата.
Я говорю о сопровождении проекта.
Был и я в ситуации с непорядочным заказчиком
Сайт заказчика плелся в хвосте у поисковок; задача была поработать над сайтом, чтобы вывести в топ поисковок. Денег на тот момент у заказчика не было, договорились, что за работу заказчик мне не платит, а я в качестве оплаты размещаю на сайте коммерческие статьи из миралинкса. Нормально отработали пару лет, сайт нормально поднялся, и я что-то заработал. Потом бывший заказчик решил меня "кинуть" - удалил размещенные мной коммерческие статьи; таким образом (по правилам миралинкса) я должен был уже за свои деньги переразместить эти статьи на других сайтах.
Заказчик конечно в какой-то мере сам себя наказал: удаленные статьи были частью стратегии продвижения, и сайт снова стал опускаться в поисковках. Но и я попал на некую сумму денег, заставившую меня на пару месяцев подзатянуть пояс.
Фактически, после двух лет работы, меня в одночасье вынудили вернуть все заработанные деньги.
Заказчик конечно в какой-то мере сам себя наказал: удаленные статьи были частью стратегии продвижения, и сайт снова стал опускаться в поисковках. Но и я попал на некую сумму денег, заставившую меня на пару месяцев подзатянуть пояс.
Фактически, после двух лет работы, меня в одночасье вынудили вернуть все заработанные деньги.
_____________
Бесплатному сыру в дырки не заглядывают...
Здесь расположена полная версия этой страницы.