Меню
Что нового?

Хранения ядра в одном месте

  • Автор темы Автор темы ChesterOne
  • Дата начала Дата начала

ChesterOne

Guest
Хранениe ядра в одном месте

Я планирую сделать CMS систему (да, знаю их как собак нерезанных, но все же). Так как она будет использоватся на многих сайтах, то я думал хранить неизменную часть, так называемое "ядро" в одном месте. Ведь глупо дублировать его для каждого клиента.
Так как CMS-ка будет предоставлятся вместе с хостингом, то и она и сайты будут на одном сервере, следовательно подгрузка ядра не должна тормозить.
Подумал, и решил просто открывать файл ядра для запуска всем. И в нем просто проверять права. Но возникла проблема, если php файл инклюдится из другого виртуального хоста, то для него ничего недоступно. Ни переменные, ни константы.
Подскажите, пожалуйста, как лучше хранить ядро?
Спасибо.

-~{}~ 04.11.04 16:26:

И даже более того. Я планировал, на сайте клиента хранить лишь логин с паролем к аккаунту, и сразу же грузить ядро.
Ядро в свою очередь получив данные лезет в БД, грузит все шаблоны, модули, параметры для данного аккаунта. На выходе получаем готовую страницу. Как думаете, реально такое? Или ,бред?
 
Т.е. будучи твоим клиентом я смогу написать модуль, благодаря которому упадут все остальные твои клиенты?
 
В общем этот файл запуска будет в скомпилированном виде. И закрыт для записи от фтп аккаунта клиента
 
ChesterOne
1. Если файл инклюдится откуда угодно, то он становится составной частью "инклюдящего" файла. И, соответственно, для него доступны все определённые в "инклюдящем" файле переменные, константы и т.п.
2. Что значит "открывать файл ядра для запуска"?

...и даже более того :) Многое из того, что де-факто является бредом - вполне реально. Здесь же я вижу попытку реализовать нечто вроде DCOM. Или я неправ?
 
Э, я в этих ДКом не силен. Но для того чтобы инклюдить файл нужны права. А то ведь можно было бы, все что угодно за инклюдить и увидеть все переменные. Надо открывать файл для Exec.
Я на локалхосте пробовал инклудить файл из другого вирт. хоста, он невидит переменных и т.д. :(
 
Автор оригинала: ChesterOne Я на локалхосте пробовал инклудить файл из другого вирт. хоста, он невидит переменных и т.д. :(
Нажмите для раскрытия...
Каким образом? include 'http://virtualserver/script.php';? И не должен, поскольку это HTTP-запрос. Если же include '/path_to_virtualserver/script.php', то не вижу причин, чтобы переменные не были видны. Однако, имхо, и тот, и другой способ позволяет клиенту тебя сломать - может ошибаюсь.
 
А как же мне узнать настоящие пути до файлов?
Простите за глупый вопрос :)
И вообще, ведь скриптам нельзя выходить за рамки выделенной им директории :(
 
все говорят, что мы вместе
все говорят, но немногие знают в каком
 
И вообще, ведь скриптам нельзя выходить за рамки выделенной им директории
Нажмите для раскрытия...
Очень даже можно если не включён safe_mode и прочие директивы типа safe_mode_include_dir и не установлена open_basedir
 
2 Gas
Ого! Так значит все клиенты на одном сервере могут друг друга инклюдить?
Наверное у всех стоит safe_mode_include_dir
 
По поводу проблемм безопасности Shared хостинга, может пригодитсяэто
 
Спасибо. С путями все ясно. А вообще насчет хранения на сайте клиента только данных по аккаунту и инклюда ядра что думаете? Оправдано ли это?
Если я скомпилирую этот файл вызова и закрою для него фтп доступ, то это будет безопасно?
 
ChesterOne
"Если я скомпилирую этот файл вызова и закрою для него фтп доступ" - что бы это могло означать?
 
:)
Скомпилирую Zend Optimizator - ом, и для фтп аккаунта клиента выставлю readonly атрибут.
 
ChesterOne
Не вижу связи между инклюдом и "read-only" на фтп. Или ты собираешься по фтп инклюдить? Тогда скорость падает - даже на в пределах локальной машины установление http/ftp соединения занимает некоторое время. И к тому же файловая система имеет обыкновение кешировать файлы, в отличие от.
В целом - это не проблема конкретно твоей CMS - это гораздо более общий и абстрактный вопрос защиты многократно используемого кода.
Если таки обработать encoder-ом (и при отсутствии дыр в коде, разумеется) - то вполне можно раздавать "в аренду" пользователям.
 
Cougar
Компиляция нужна для того, чтобы пользователь не мог увидеть данных которые передаются ядру. А ReadOnly для того, чтобы он не мог заменить файл вызова своим файлом.

Инклюдится же будет обыкновенным образом, а не по фтп.

-~{}~ 05.11.04 06:04:

Этот файл вызова будет перехватывать все обращения к html страницам сайта ModRewrite-ом. И соответсвенно передавть ядру
PHP: 
$REQUEST_URI;
Вот и все что он него требуется.
А что? По моему не плохо. Т.е. если ядро грейдится, то все клиенты будут сидеть на новом ядре.
Так же ядру доступны все необходимые классы. HTML шаблоны хранятся в БД для клиента.
 
Войдите или зарегистрируйтесь для ответа.
Сверху