Looking for pattern to protect lookup values

Looking for pattern to protect lookup values

Old forum URL: forums.lhotka.net/forums/t/8287.aspx


bgilbert posted on Tuesday, January 05, 2010

In my application, there are several values in several lookup tables that are tied to code, either through enums, settings, or resources. For example, I have a DefectCodes table that contains a key that is referenced in code to trigger certain app behaviors. I want to allow my users to maintain certain fields in this record, but not to be able to change the key. I currently accomplish this with hard-coded rule methods in each class that check for changes to those values.

It's started to become a big enough issue that I'm looking for a more generically applicable solution. Nothing I've come up with so far is elegant enough for my taste and I'm wondering if anyone else has tackled this problem.

Thanks,
Barry Gilbert

rsbaker0 replied on Tuesday, January 05, 2010

I expect that CSLA authorization rules might provide a possibility (e.g. it might be feasible use them to to deny any role the ability to write the property).

Another technique I have used is to make the property setter for such values "internal" while the getter is still public.

You can grant access to your business or data layer (if it lives in another assembly) the ability to write such internal properties via the InternalsVisibleToAttribute, if that becomes an issue. This combination prevents the UI layer (presumably in other assemblies that are not granted write access to internals) from directly writing such values, but you still have the ability to do so when necessary (e.g. to load the data).

bgilbert replied on Tuesday, January 05, 2010

Thanks for your reply. I may not have been clear enough in my description.

I need to protect the Id/key property only for certain records, not all records. Using my previous example, my DefectCodes table may have 150 records, but there are two records whose Id value have special meaning in my code and therefore cannot be changed. All other records are fair game. We are using property-level permissions, however CSLA has no accommodation for record-level or value-level permissions.

rsbaker0 replied on Tuesday, January 05, 2010

Actually, CSLA has both instance (record-level) validation rules as well as authorization rules, although I think Rocky is on record as wanting to phase out the instance validation rules.

If you're already using the property level authorization rules, perhaps you could add instance rules for the protected records.

RockfordLhotka replied on Tuesday, January 05, 2010

You can override CanWriteProperty() in a specific object to create context-specific authz rules. In other words, you could always return false for a specific property, if that property's value was one of your restricted values.

bgilbert replied on Tuesday, January 05, 2010

Rocky,

Thanks for your suggestion. This is what we're currently doing. I was looking for a more abstract way of handling this. One thought is to have a boolean column in each lookup table indicating whether the Id can be modified and then creating a centralized rule method that evaluates this value. I'm not sure it's worth the brain damage, though.

Thanks.

ajj3085 replied on Wednesday, January 06, 2010

I would do as you plan, but don't use a rule method, just override CanWriteProperty.  You're not gaining a lot by centralizing a few lines of code.  If you feel you must, maybe you can have a superclass which encapsulates this behavior.

Copyright (c) Marimer LLC