A better way to describe CRUD in a web application?

Question

Hello,

We've been refactoring our web-based admin application (again) and got a bit stuck when describing the permissions involved in what we used to call CRUD (create-read-update-delete) operations. We've found that simply trying to describe an action/permission in terms of CRUD doesn't really apply to a web-app. It seems that CRUD as a concept is split over the scope of the data - both in the database and in the application model:

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

We're struggling to come up with a concise permissions table without mixing up the scope. For example, if I want to create a new product, I must have access to READ the products table, READ and CREATE a product row, and also have READ and UPDATE access to the product name field... all of which adds up to a very messy permissions-tree! At the moment, we have silly methods like hasAccess($object, $user_ID) all over the place and nested 'n' levels deep in if/else statements to cater for the situation above.

Are there any other well known ways to describe user permissions without resorting to CRUD?

Thanks for your help!

(and, before you ask, yes we have looked at many frameworks to see how they do it, and no, I can't see my example in the documentation!)

Answer 1

you have described a database layer type of security model - which works well, especially if you have direct database access from outside your application.

If you have no external database access, you may consider creating security on your business objects, and not on the data model objects.

in your example, your would create a class for PRODUCT, and give permission like CREATE, which implies various levels of actual privilege in the next layer down (data layer).

If you have the possibility of data corruption from some admin using a command line, then maybe you want to stick with the database level constraints to always ensure integrity.