Лучший способ описать CRUD в веб-приложении? - PullRequest
Новая
       6

Лучший способ описать CRUD в веб-приложении?

2 голосов
/ 30 августа 2010

Мы реорганизовали наше веб-приложение администратора (снова) и немного застряли при описании разрешений, связанных с тем, что мы использовали для вызова операций CRUD (create-read-update-delete).Мы обнаружили, что простая попытка описать действие / разрешение в терминах CRUD на самом деле не относится к веб-приложению.Кажется, что CRUD как концепция разделена по объему данных - как в базе данных, так и в модели приложения: 

Scope    Permissions               Example
-----    -----------               -------
Table    READ                      I can view a list of all orders
Row      READ | CREATE | DELETE    I can view an individual product, I can create a new product and I can delete it from the database
Field    READ | UPDATE             I can view and update a customer's username

Мы изо всех сил пытаемся придумать краткую таблицу разрешений, не смешиваясфераНапример, если я хочу создать новый продукт, я должен иметь доступ к ПРОЧИТАТЬ таблицу продуктов, ПРОЧИТАТЬ и СОЗДАТЬ строку продукта, а также иметь ЧИТАТЬ и ОБНОВИТЬ доступ к полю имени продукта ... все это в сумме даеточень грязное дерево разрешений!На данный момент у нас есть глупые методы, такие как hasAccess($object, $user_ID) повсеместно, и вложенные уровни 'n' глубоко в операторах if / else для удовлетворения ситуации выше.

Существуют ли другие хорошо известные способы описанияразрешения пользователей без обращения к CRUD?

Спасибо за вашу помощь!

(и, прежде чем вы спросите, да, мы посмотрели на многие фреймворки, чтобы увидеть, как они это делают, и нет, я могуне вижу мой пример в документации!)

1 Ответ

1 голос
/ 30 августа 2010

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

Если у вас нет доступа к внешней базе данных, вы можете рассмотреть вопрос о создании безопасности для ваших бизнес-объектов, а не для объектов модели данных.

в вашем примере вы создадите класс для PRODUCT и дадите разрешение типа CREATE, что подразумевает различные уровни фактических привилегий на следующем нижнем уровне (уровне данных).

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

...