As you see from other posts, there is more than one way to do things.
It is up to you to decide which one is more appropriate, considering
flexibility, performance implications and so on. So here is an overview
with a few important additions that haven't been mentioned.
1. Security checks on commit. As recommended by Eric, "validate*"
methods is a way to go, as the validation will be done at the object
level, so you can check both entity and row-level rules.
2. Security checks on object access. Mike's solution of overriding the
setters allows to apply the rules even before object is committed. I
can suggest a modified version of this solution that maybe more
appropriate if you don't want to go as a low as object properties -
override CayenneDataObject.setPersistenceState(..). This way you can
track persistent state transitions of individual objects and apply the
rules (e.g. when an object is transitioned between TRANSIENT and NEW,
between anything and DELETED, between anything and MODIFIED).
Note that "anything to COMMITTED" transition check won't work, as
objects has been committed to DB already by this point. Now I am
thinking that this is rather arbitrary and we may need to fix it.
3. Organizing Entities into DataDomains. This feature is often
overlooked, but DataDomains are there for the sole purpose of providing
coarse-grained access security. It has many advantages over other
approaches, as it is declarative and completely controlled by the
framework. There are a few limitations though. You can't go lower than
entity-level security. Also it is not as dynamic, i.e. you'll have to
define what entities are accessible within a given DataDomain upfront.
But if you can map your security roles to a set of entities,
DataDomains can be very helpful.
Defining "read-only" entities and entity qualifiers per DataDomain are
two "creative" ways to make DataDomains approach more flexible.
Andrus
On May 17, 2004, at 10:45 AM, Mehdi Bennani wrote:
> Hey Cayenners,
>
> I understand that Cayenne is a data modeling tool, and a security
> model may not be the main focus of the tool. But, I was just wondering
> if you guys thought of that at some point and what would be the best
> approach for it.
>
> By Security model, I mean a way for the developer to attach
> permissions to the different objEntities, so that only authorized
> users can update/delete/insert the objEntities. Also, eventually
> permissions on the rows in the database and so on... We have the need
> for that sort of implementation in our projects.
>
> We are thinking of build this model around the objEntities as the
> smallest level of granularity. It could certainely be used at the
> datacontext level also...
>
> So, I was wondering if you already had an idea on how/where this could
> be plugged in...
>
> Sincerely,
>
> Mehdi Bennani
> Software Engineer
> FreeBalance Inc.
> Visit the new FreeBalance website..www.FreeBalance.com
>
> T (613) 236-5150 ext.325
> F (613) 236-7785
> mbennan..reeBalance.com
This archive was generated by hypermail 2.0.0 : Mon May 17 2004 - 13:16:41 EDT