Модульная система на PHP, как защитить?

Question

[Карл Майнхофф]

Возникла необходимость написать проект на PHP5, так называемое ядро для последующего написания и подключения к нему модулей. Проект рассчитывается на то, чтобы модули к нему писались не только моими руками, но и другими пользователями. Если конкретнее, модуль будет скорее всего представлен в виде файла, содержащего класс модуля. Сейчас же меня интересуют следующие пункты:

• Как ограничить модулю доступ к базе данных в пределах одной таблицы?
  
• Как запретить модулю include файлов ядра?
  
• Как запретить модулю выполнение некоторых функций в любом проявлении?
  

Не подскажете, куда курить, какие библиотеки или способы применят?

Answer 1

[MetaDone]

модуль будет скорее всего представлен в виде файла, содержащего класс модуля

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

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

Comments

[Карл Майнхофф]

Насколько я понял эти принципы, они дают возможность быстро изменять код и удобнее тестировать его. Честно говоря, не совсем понимаю, как с помощью этого дела можно ограничить доступ модулям.

[MetaDone]

Карл Кремень: смотрите, к примеру есть у вашего модуля один контроллер. Хорошо, он должен делать что-то полезное и как можно меньше знать о всей остальной системе. Ему нужно брать данные для работы откуда-то, так что ему нужна какая-либо связь с хранилищем.
Далее - ваш репозирорий/модель для модуля/сущность active record/что-то что общается с хранилищем должно данные откуда-то доставать и не знать ничего более.
Получается, что ваше ядро создает экземляр вашей сущности для работы с данными, передает ей с какой таблицей оно работает, передает ей что-то что может достать данные из хранилища. После всю эту сущность передаем контроллеру модуля, который уже будет дергать методы этой сущности.
Если хотите как можно сильнее ограничить модуль, то можно написать интерфейсы для сущностей, на их основе реализовать такие базовые сущности для таблиц, с которыми будут работать модули, а потом с помощью контейнера зависимостей объявить связи сущностей с интерфейсами и уже их передавать в типа контроллер модуля. тогда можно будет обойтись одним файлом
например выйдет так
https://gist.github.com/MetaDone/4ad23763b3027e116...

[Карл Майнхофф]

MetaDone: Сие я понял. Теперь вопрос: как запретить модулю в одной из своих функций напрямую вызывать, например, PDO?

[MetaDone]

Карл Кремень: напрямую вы не запретите дергать что угодно, что есть в системе. Если хотите ооочень жестко проверять что модуль действительно будет использовать только то, что есть в системе и ничего более, то смотрите здесь - php.net/manual/ru/book.reflection.php. можно проверять заданы ли соответствующие свойства, определены ли нужные интерфейсы и много чего еще. В случае несоответствия выбрасываете исключения, но даже так это можно обойти.
или же смотрите в сторону https://zephir-lang.com/ и оформите свой код как расширение, так точно скроете детали реализации, а интерфейсы подскажут конечным пользователям что нужно реализовывать в рамках модуля и что они могут использовать

[Карл Майнхофф]

MetaDone: zephir мне не подходит, ибо у меня может не быть доступа к тому же php.ini, чтобы добавить расширение, и уж тем более к консоли, чтобы собрать расширение. Но если совсем больше ничего не смогу найти, то придется воспользоваться им.

[Карл Майнхофф]

MetaDone: И да, я все равно не вижу возможности закрыть от использования стандартные PHP-функции. Есть вариант использовать что-нибудь типа своего скриптового языка или прикрутить парсер Lua, который доступен в PHP7

Answer 2

[novrm]

Может не совсем понял - но вы пишите свой велосипед-фреймворк...
Чем вам не угодили, например, Zend или Symfony?

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