Выделить ядро-логику движка как базу (основу) для разработки сайтов

[Andrey Rodin]

Я работаю над сайтами со своим с нуля написанным кодом. Система расширяемая и пока не вижу причин бросать работу с ней. Единственное, что не могу реализовать, а точнее могу, но есть загвоздка в безопасности.
Система построена, используя концепцию HMVC. Несколько базовых классов, основные модели (разделы, статьи, новости, работа с блоками на сайте), шаблонизатор Smarty - все это формирует основной функционал.
В ходе работы постоянно появляются полезные наработки, которые не плохо бы было добавить в эти базовые классы. Т. к. базовый код с появлением нового сайта дублируется, внесение дополнений довольно трудоемкое занятие. Недавно я выделил базовый код и вынес его. Грубо говоря, раньше вся логика находилась в папке "home/account_name/www/class" , теперь "home/account_name/engine". Точка входа (index.php) теперь подхватывает необходимые классы через autoload-функцию. Логика сводится к следующему:
Первым делом проверяется папка с логикой самого сайта "home/account_name/www/class" на наличие необходимого класса и если он найден, то берем его. Если нет, то берем класс из базового кода.
Таким образом удалось на базе одного скрипта построить четыре сайта, при необходимости дополняя функционал необходимыми классами в папке логики самого сайта.
Кроме того, казалось бы, удалось скрыть реализацию от третьих лиц и предотвратить "кражу", утечку (или как это еще можно назвать?) кода,
Проблема состоит в следующем:
В моем распоряжении VPS сервер. Для каждого клиента имеется свой (user) аккаунт. Есть и личный (admin) аккаунт. Весь базовый скрипт лежит на личном "home/admin/engine". На данный момент "клиенты" используя autoload-функцию через include подключают нужные файлы. Но при желании содержимое всей "базы" можно получить.
Посоветуйте пожалуйста, как предотвратить это. Может где-то это уже реализовано? Спасибо

 

[С.]

Не понятно, что ты пытаешься защитить. Общий код? Ну так на то он и общий, что бы любой из клиентов мог его использовать. Защите не подлежит.

 

[craz]

Не понятно, что ты пытаешься защитить. Общий код? Ну так на то он и общий, что бы любой из клиентов мог его использовать. Защите не подлежит.

его можно обфусцировать же, не? хотя это опять же "Неуловимый Джо"

 

[Andrey Rodin]

говоря простым языком. Разрешить использование базового кода (include) для любого аккаунта только файлов из определенной папки и папок его акаунта, запретить любые ltqcndbz аля file_get_content для папок и файлов, что лежат вне его аккаунта

 

[Фанат]

Правило, которое работает в 100% случаев:
Если программиста заботит вопрос, как скрыть свой код от третьих лиц, то код такой, что и даром никому не нужен.

 

[craz]

Кстати да, сначала его заботит как бы у него его не своровали(неуловимый Джо), потом он начинает выкладывать куски кода на обсуждение и понимает, что его код полное гавно, тогда он выкладывает весь код в опенсурс, и если кто-то когда-то ему поможет уже сделать реально что-то работающее вот тогда то и начинается нормальная проблема защита кода. Только такие уже не спрашивают на форумах как да что.

 

[С.]

говоря простым языком. Разрешить использование базового кода (include) для любого аккаунта только файлов из определенной папки и папок его акаунта, запретить любые ltqcndbz аля file_get_content для папок и файлов, что лежат вне его аккаунта

Эта проблема решалась теми или иными способами в эпоху shared хостинга. Shared хостинг на VPS попахивает студенческим онанизмом. Ну если приспичило, то исследуй старую тему shared хостинга.

 

[Redjik]

Может он хочет защитить программеров от кода? Мы же не знаем =)

 

[Andrey Rodin]

Эта проблема решалась теми или иными способами в эпоху shared хостинга. Shared хостинг на VPS попахивает студенческим онанизмом. Ну если приспичило, то исследуй старую тему shared хостинга.

Есть какой-либо другой вариант размещения сайтов клиентов равный аналогичному по стоимости?

 

[Andrey Rodin]

Может он хочет защитить программеров от кода? Мы же не знаем =)

Накинулись... Молодцы. "Мое кунг-фу круче твоего". Ну оно то и понятно...

 

[Andrey Rodin]

Правило, которое работает в 100% случаев:
Если программиста заботит вопрос, как скрыть свой код от третьих лиц, то код такой, что и даром никому не нужен.

Я хочу скрыть не базовый код, а код других аккаунтов. Логика всех сайтов одинакова. Т.е. имеется файл с настройками home/account1/www/settings.php Через file_get_content я могу получить его с любого аккаунта
Смысл выноса базового кода за пределы аккаунта пользователя - повторное использование без дублирования

 

[С.]

Есть какой-либо другой вариант размещения сайтов клиентов равный аналогичному по стоимости?

Если ты сам хочешь стать хостером и брать деньг с клиентов за хостинг, то подпишись на какую-нибудь реселерскую программу. Там все уже отлажено для таких слуачаев. Да это дороже, чем индивидуальный VPS, а ты как хотел? Тратить как индивидуал, а получать как бизнесмен?

Либо закупай отдельный хостинг для каждого клиента. Клиент платит.

 

[С.]

Смысл выноса базового кода за пределы аккаунта пользователя - повторное использование без дублирования

Ну вот наконец-то настоящим простым языком сказано. Вариант только один -- полноценный shared хостинг. Изучай как там организована безопасность клиентов (друг от друга). Информация в сети пока еще есть. Тема не тривиальная и вот так на пальцах ее на форуме не рассказать.

 

[Andrey Rodin]

Если ты сам хочешь стать хостером и брать деньг с клиентов за хостинг, то подпишись на какую-нибудь реселерскую программу. Там все уже отлажено для таких слуачаев. Да это дороже, чем индивидуальный VPS, а ты как хотел? Тратить как индивидуал, а получать как бизнесмен?

Либо закупай отдельный хостинг для каждого клиента. Клиент платит.

В этом случае я вернусь к своей проблеме - постоянному дублированию кода. Я не стремлюсь стать хостером, но вопрос размещения сайтов клиентов возникает постоянно. Не претендую на авторитетное мнение в этом вопросе, но перефразируя пословицу "Лучше держать свои яйца в одной корзине". Можно аргументы против моего варианта размещения сайтов клиентов на отдельных аккаунтах одного VPS?

 

[С.]

перефразируя пословицу "Лучше держать свои яйца в одной корзине". Можно аргументы против моего варианта размещения сайтов клиентов на отдельных аккаунтах одного VPS?

Пожелание вполне разумное, но дешевый VPS это не серьезно из количественных соображений. Мощности не хватит. Надо или дорогой VPS, либо выделенный сервер, цена которых примерно одинаковая. Меньше 100 долларов в месяц лучше даже не заморачиваться.

 

[Andrey Rodin]

Позчелание вполне разумное, но дешевый VPS это не серьезно из количественных соображений. Мочности не хватит. Надо или дорогой VPS либо выделенный сервер, цена которых одинаковая. Меньше 100 долларов в месяц лучше даже не заморачиваться.

1536МБ ОЗУ
2 Ядра Intel Xeon E5645
20GB SSD-диск
100Mbit порт

 

[С.]

Дело хозяйское. Ищи и читай, как защищать друг от друга клинетов шаред хостинга. Там несколко подходов, каждый не без изъяна. Идельная защита при полной свободе делается только через VPS (один на каждого клиента).

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

 

[Фанат]

В этом случае я вернусь к своей проблеме - постоянному дублированию кода.

Да с какой стати-то?
Как минимум - симлинк решает проблему. Не считая ещё кучи способов не дублировать код.

 

[Ярослав]

Блин вообще не понятно при чем тут защита? Защиту нужно делать в рамках одного проэкта. Проекты не должны знать друг о друге!

ИМХО способ решить данную проблему топикстартера:
1. Хостинг не трогаем. Отдельные акаунты должны быть разделены
2. Делаем в проекте директорию engine, тут будут лежать общие сорцы (локально их линкуем либо симлинками, или через svn:externals, способов много...)
3. При обновлении библиотеки, обновляем все! проекты, где мы хотим видить эти изменения. Каждый проект будет работать со своей папкой engine.
4. Проэкт должен обновляться желательно одной командой из консоли девелоперской машины. К примеру через rsync или lftp с указанием игнора списка файов (конфиги, загруженные картинки и т.д.)

 

[Redjik]

Я как то тоже с этим заморачивался, но умный человек fixxxer направил меня на путь истины =) И я НЕ стал экономить 50 метров на движок и различные модули.
Живу счастливо, не парюсь, что при обновлении что-либо отвалится на других сайтах.

В принципе - сделал и забыл.