Как при разработке сайта ограничить доступ к исходникам?

Question

[Mock]

Есть финансовый проект, на 80% готовый. Нужно доработать некий функционал. Доступ к исходникам давать не хочется.

Что придумано на данный момент. Работа через какой-нибудь Тим вьювер на серверной машине, где проект развернут на локалке.

Но как быть с переносом на основной рабочий домен? Ведь в процессе работы на локальном сервере через Тим вьювер вполне может быть что зальется какой-нибудь шелл или будет сделана уязвимость «под себя», чтобы при случае заглянуть в гости и стырить все что можно

Всякие там бумажки об ответственности, договора и так далее — это все фигня и никаких гарантий не дает.

Answer 1

[edogs]

Вот поэтому нужно делать модульные проекты, что бы при доработке «некоторого функционала», не нужно было бы давать глобальный доступ ко всему проекту. Ну а сделанную работу на предмет всяких шеллов должен проверять доверенный разработчик, который все равно должен присутствовать.

Comments

[Mock]

К сожалению нету отдельного разработчика, который все это может проверить

[qxfusion]

Как правило для крупного финансового проекта всегда есть хотя-бы один главный разработчик (Senior Developer) — без этого Вы не сможете проконтролировать правки.

Answer 2

[gaelpa]

Принимать работу по «диффу». Все, что будет добавлено исполнителями будет заметно, а дальше уже вопрос компетентности тех, кто будет просматривать это добро на закладки.

Answer 3

[Игорь]

Лучше всего, конечно, модульность, как уже советовали.
Можно ещё рассмотреть вариант обфускации кода и передаче его всего обфусцированного. Редкая птица захочет восстанавливать его функциональность

Comments

[Иван Журавлев]

Обфускация не спасёт от внедрения туда шелла. Раскрутят самую первую обёртку, добавят свой код и обратно упакуют причём точь в точь, даже не поймёшь.

[Игорь]

Обфускация поможет препятствовать модификации функционала в той её части где она не нужна. Т.е. у того, кто дорабатывал, будет весь проект. Но сплагиатить весь проект будет довольно проблематично

Answer 4

[Rafael Osipov]

Как вариант — разбейте проект на несколько модулей. Модули, которые вы не хотите открывать, пусть живут на вашем хостинге и наружу смотрит только некий ваш API для обращений извне.

Модуль, который дополнит функциональность системы, пусть разрабатывает команда сторонних разработчиков. И разрабатываемый модуль пусть общается с вашей существующей системой через веб-сервисы. После того как новый модуль будет разработан, вы его проверите на наличие закладок и интегрируете в общую систему.

Answer 5

[Александр Скляров]

Обратится к изначальному разработчику сего проекта, он и так знает все его «дыры», или кого-то «знакомого» что тоже не показатель. Других вариантов быть просто не может. Например сидеть следить за работой в режиме реального времени, но тогда возникает вопрос в целесообразности, следящий должен превосходно разбиться в том за чем следит, чтобы не «прозевать» искомое

Answer 6

[demimurych]

внутри своих исходников спрятать свой шелл.