I have, I hope, a simple question in regards to authorization with collections and children,
I have a root collection with an unknown amount of children. In my scenario, I have authorization rules that are placed on the children. I have placed these rules in the child class.
When I interact with the object, these rules appear to be ignored. (In one test, the rules should have prevented me from saving, but no check was performed.)
If the child contains the rules, will the collection enforce or ignore the authorization rules?
Using CSLA 4.3.13
The collections will NOT enforce child authorization rules (CanCreate/CanEdit/CanDelete...)
This must be handled by YOUR code.
IE: The "root" object will be enforced by the "root" DataPortal - but if you want to check
authorization for all Child/GrandChild/.... then this must be done by YOUR code.
There's already have an item in the BugTracker for this but not prioritized for any release, yet.
Just to clarify, authorization rules will not descend?
I am asking as the bug appears to be in regards to the collection events.
I ask as the following events I have on the children: AuthorizationActions.CreateObject, AuthorizationActions.DeleteObject, AuthorizationActions.EditObject,
AuthorizationActions.GetObject need to be checked for each child in the collection. I will have to manually check these?
Also, I understand there may not be an answer to this question. If and when bug 945 is implemented, do you know if it will be only on the first level, or will the authorisation check cascade up all the children? (IE, grandchildren and etc.)
The idea would be that the user is only allowed to:
These should ALL only be checked for when calling these actions. IE: The user should only be allowed to add/remove children when authorized and CSLA should not need to recheck this within the context of a Save method. So the user should not be allowed to do more actions/edits than the user is authorized for.
CanEditObject is today - only checked on the "root" object - when calling a Save method (and the object has both IsNew and IsDeleted = false) .
I do NOT know if this will cascade down to each child object when bug 945 is implemented.
Here is a bit of an issue for myself. Our security is not a simple role based security. It is a combination role with a hierarchy. To check security, I need to examine part of the object's information. When the collection is loaded, there may be a mix of editable and non editable objects in the collection. Without having the individual objects maintaining this, it may be a lot of manual work to probe these collections.
I see the property checks are done in the child objects. I'd rather not, but should I set the security on the properties as opposed to the object?
Copyright (c) Marimer LLC