[Dbix-class] Enforcing read-only objects

Ian Docherty (icydee) dbix-class at iandocherty.com
Wed Aug 11 19:03:58 GMT 2010


Bill
It really sounds to me that what you are describing are the 'business 
rules' of your application and as such I think you are missing a trick.

If it were me, I would not be trying to twist DBIC into knots to support 
this logic, but put a separate business layer between the application 
and DBIC within which you implement this logic.

So, you would provide methods in your business layer to update the 
objects, and this would do the checking before making calls to the DBIC 
layer.

In my opinion, if you are putting ->update, ->create, ->delete, ->update 
methods in your application then this is wrong.

It also means that if you have some background process that *does* need 
to do an update on this data, irrespective of the user_access, then it 
can still do so (via the business logic) whereas with your solution you 
are preventing this from working too.

Regards
Ian

On 11/08/2010 16:44, Bill Moseley wrote:
> I'm looking for your suggestions on enforcing access policy within DBIC:
>
> In my Music database I have a hierarchy of objects like this:
>
>     notes -> tracks -> cds -> artists -> label -> user_access -> users
>
>
> The user_access table links users with a label.  When I fetch an object
> from the database I join to the users table to make sure the user has
> access to the label.  If no row in user_access then the user has no
> access at all.
>
> Now, the user_access table also has a read_only flag.  My plan here is
> when I join to user_access to add a column to every object called
> "is_readonly" so that code can look at any row object and determine if
> it's read-only or not.
>
> But, I also want to enforce the read-only state in the model.  And this
> is where I need some ideas.
>
> One idea would be to alter the schema so there's no storage associated
> with a read-only object (so calling ->update would die).  I'm not sure
> how to implement that.
>
> Another idea is to override update() and delete() and look for the
> is_readonly flag and abort the "is_readonly" flag exists on the object.
>
> Both of those don't work with create, though.  So, I'm wondering about
> adding a call before create() that calls can_create() which would be a
> class method that would know how to test a given create.  For example,
> trying to insert a new note, the "Note" class would test that the track
> id passed to create() can be joined to the user via the user_access
> table and that the user_access.read_only flag is false.
>
> (Yes, the "current_user" is available to DBIC as it's stored in the
> schema object.)
>
> Other suggestions?
>
>
> Thanks,
>
>
> --
> Bill Moseley
> moseley at hank.org <mailto:moseley at hank.org>
>
>
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk




More information about the DBIx-Class mailing list