[FLOW3-general] ContentSecurity with collections

[Andreas Förthner]

Hi Ferdinand,

I think it's just not supported what you are currently trying. But I don't
know if I got everything right. Could you send the complete resource
definition and the according queries in your repository?

Greets Andi

Am 12.11.11 22:41 schrieb "Ferdinand Kuhl" unter <fcool at coolys.de>:

>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
>
>
Andreas Förthner
Leiter Web-Entwicklung

Telefon: +49 (911) 539909 - 0
E-Mail: andreas.foerthner at netlogix.de
Website: media.netlogix.de


--
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Internet: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt



_______________________________________________
>FLOW3-general mailing list
>FLOW3-general at lists.typo3.org
>http://lists.typo3.org/cgi-bin/mailman/listinfo/flow3-general