[FLOW3-general] ContentSecurity with collections

[Ferdinand Kuhl]

In simple cases yes.
But try the following rule:

this.COLLECTIONPROPHERE.SIMPLEPROPERTYHERE != "BLABLUB"
Works on the query (list) level.
But you will never be able to fetch a single entity.

Bernhard Fischer wrote:

> Hmm ... in my configuration it works as (I) expected. Entities which
> where denied will never be shown or couldn't be retrieved. In 
general
> I'm still not quite sure how to use content security. Maybe because 
it's
> totally different from acls for methods, I still do not get the
> principles behind it?
> 
> Greetings
> Bernhard
> 
> On 11/12/2011 10:16 PM, Ferdinand Kuhl wrote:
>> Hi Bernhard,
>>
>> I did not try to use it in different ways. I just want to manage
>> access at all.
>>
>> But the situation is as followed: Listing shows the entities as
>> configured. Retrieving these entities does not work. This cant be 
as
>> intended ;)
>>
>> Greetz,
>> Ferdinand
>>
>>
>> Bernhard Fischer wrote:
>>
>>> Hi Ferdinand,
>>>
>>> I think it isn't intended to differ between modify, delete or 
simple
>>> queries with content security. It "only" manages access at all in 
a
>> very
>>> comfortable way. I'm still trying to resolve this problem with an
>>> abstract repository class. Maybe AOP would be a better way, but 
I'm
>> not
>>> used in aspects.
>>>
>>> Greetings
>>> Bernhard
>>>
>>> On 11/12/2011 04:09 PM, Ferdinand Kuhl wrote:
>>>> Hi list,
>>>> another problem with content security :(
>>>>
>>>> If you use rules like:
>>>> this.collection.subProperty = current.securityContext.party
>>>>
>>>> everything works fine on the query level.
>>>>
>>>> But if you try to fetch (for modification or show) such an object
>> the
>>>> PersistenceQueryRewritingAspect does not allow those objects.
>>>>
>>>> Function checkSingleConstraintDefinitionOnResultObject fails to
>>>> resolve the "this.collection.subProperty" and thus denies access 
to
>>>> the object.
>>>>
>>>> I tracked the problem down to
>>>> Reflection\ObjectAccess:getInternalProperty where such resolving
>> fails
>>>> in first place. But modifying it to return those requests as 
array
>>>> does not help either, because the rule array != scalar later on 
can
>>>> not work.
>>>>
>>>> Any Ideas or plans on this?
>>>>
>>>> Greetings,
>>>> Ferdinand