I don't think that we need to change the visibility or need to add setters,
we just need to pass the fully-qualified class name of the entry class when
getting the reflection property instead of passing the object instance.

Kind regards,
Johannes


On Mon, Apr 4, 2011 at 6:19 PM, Gustavo Adrian
<[email protected]>wrote:

> For now I just changed the visibility of the Entry::$id property to
> protected, and now it works fine. Your suggestion should work too, but I
> think in this special case it's better to change the visibility instead of
> adding setters. A user shouldn't change directly a value of a property of an
> Entry instance. This is handled by the AclProvider. What do you think?
>
>
> Thanks a lot for your comments and the useful info!
>
>
>
>
> 2011/4/4 Yader Hernandez <[email protected]>
>
>> Oh I see.
>>
>> There is in my opinion, a better way of handling this.
>>
>> Instead of accessing a private property which defeats the purpose of it
>> being private in the first place, a call to a setter method would work.
>> This would allow us to think more abstractly and less on implementation.
>>
>> But it looks like those were not put into place so maybe changing the
>> scope might work just as easily.
>>
>> Anyway, if the setters were in place, using ReflectionMethod::invoke()
>> would work for what you need.
>>
>> Check out the example that is already provided there:
>> http://us.php.net/manual/en/reflectionmethod.invoke.php
>>
>>
>>
>> On Mon, Apr 4, 2011 at 11:18 AM, Gustavo Adrian <
>> [email protected]> wrote:
>>
>>> It's a bug in PHP. As I said before... I'm having this problem when I try
>>> to update FieldEntry objects (Field ACEs). Lines 779, 780 and 781 of
>>> MutableAclProvider uses:
>>>
>>> $aceIdProperty = new \ReflectionProperty($ace, 'id');
>>> $aceIdProperty->setAccessible(true);
>>> $aceIdProperty->setValue($ace, intval($aceId));
>>>
>>> First line throws an exception saying "id" property doesn't exist. With
>>> your code, it's the same thing. It doesn't show any inherited private
>>> property. Read the second comment on the PHP bug.
>>>
>>> 2011/4/4 Yader Hernandez <[email protected]>
>>>
>>>> No need to change the visibility. You can flag what you need.
>>>>
>>>> class Foo {
>>>>     public    $foo  = 1;
>>>>     protected $bar  = 2;
>>>>     private   $baz  = 3;
>>>> }
>>>> $foo = new Foo();
>>>> $reflect = new ReflectionClass($foo);
>>>> $props   = $reflect->getProperties(ReflectionProperty::IS_PUBLIC |
>>>> ReflectionProperty::IS_PROTECTED | ReflectionProperty::IS_PRIVATE);
>>>>
>>>> foreach ($props as $prop) {
>>>>   echo $prop->getName();
>>>> }
>>>>
>>>> echo "\n";
>>>> var_dump($props);
>>>> echo "\n";
>>>>
>>>>
>>>> Output:
>>>> ------------
>>>>
>>>> array(3) {
>>>>   [0]=>
>>>>   object(ReflectionProperty)#3 (2) {
>>>>     ["name"]=>
>>>>     string(3) "foo"
>>>>     ["class"]=>
>>>>     string(3) "Foo"
>>>>   }
>>>>   [1]=>
>>>>   object(ReflectionProperty)#4 (2) {
>>>>     ["name"]=>
>>>>     string(3) "bar"
>>>>     ["class"]=>
>>>>     string(3) "Foo"
>>>>   }
>>>>   [2]=>
>>>>   object(ReflectionProperty)#5 (2) {
>>>>     ["name"]=>
>>>>     string(3) "baz"
>>>>     ["class"]=>
>>>>     string(3) "Foo"
>>>>   }
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>  On Mon, Apr 4, 2011 at 9:26 AM, Gustavo Adrian <
>>>> [email protected]> wrote:
>>>>
>>>>>  Hi,
>>>>>
>>>>> I've finally found the issue of this one. It seems to be a bug of PHP:
>>>>>
>>>>>
>>>>> http://stackoverflow.com/questions/1495600/reflectionclassgetproperty-for-a-private-property-in-an-inhertited-class
>>>>>
>>>>> http://bugs.php.net/bug.php?id=47808
>>>>>
>>>>>
>>>>> I'm using Ubuntu with PHP 5.3.3.
>>>>>
>>>>> What should we do with this one? it's a very annoying bug while trying
>>>>> to update an ACL with Field ACEs. Changing the visibility of properties
>>>>> ("id" in this case) on the Entry class from private to protected fixes the
>>>>> issue. I don't know if there's another case like this one on other
>>>>> properties.
>>>>>
>>>>>
>>>>> 2011/3/30 Gustavo Adrian <[email protected]>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I had random exceptions about serialization with the Entry class. I've
>>>>>> noticed all its properties are private. Also, FieldEntry extends from 
>>>>>> Entry,
>>>>>> so when I want to do something like this to delete a FieldEntry:
>>>>>>
>>>>>>         $classFieldACEs = $acl->getClassFieldACEs( $field );
>>>>>>
>>>>>>         // $classFieldACE is the ACE I want to delete
>>>>>>         foreach ( $classFieldACEs as $index => $classFieldACE )
>>>>>>         {
>>>>>>             if ( $ace->getId() === $classFieldACE->getId() )
>>>>>>             {
>>>>>>                 $acl->deleteClassACE( $index );
>>>>>>
>>>>>>                 break;
>>>>>>             }
>>>>>>         }
>>>>>>
>>>>>> Here I get an "Property
>>>>>> Symfony\Component\Security\Acl\Domain\FieldEntry::$id does not exist"
>>>>>> exception.
>>>>>>
>>>>>> Should we change the visibility of these properties to protected?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks in advance!
>>>>>>
>>>>>
>>>>>  --
>>>>> If you want to report a vulnerability issue on symfony, please send it
>>>>> to security at symfony-project.com
>>>>>
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "symfony developers" group.
>>>>> To post to this group, send email to [email protected]
>>>>> To unsubscribe from this group, send email to
>>>>> [email protected]
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/symfony-devs?hl=en
>>>>>
>>>>
>>>>  --
>>>> If you want to report a vulnerability issue on symfony, please send it
>>>> to security at symfony-project.com
>>>>
>>>> You received this message because you are subscribed to the Google
>>>> Groups "symfony developers" group.
>>>> To post to this group, send email to [email protected]
>>>> To unsubscribe from this group, send email to
>>>> [email protected]
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/symfony-devs?hl=en
>>>>
>>>
>>>  --
>>> If you want to report a vulnerability issue on symfony, please send it to
>>> security at symfony-project.com
>>>
>>> You received this message because you are subscribed to the Google
>>> Groups "symfony developers" group.
>>> To post to this group, send email to [email protected]
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> For more options, visit this group at
>>> http://groups.google.com/group/symfony-devs?hl=en
>>>
>>
>>  --
>> If you want to report a vulnerability issue on symfony, please send it to
>> security at symfony-project.com
>>
>> You received this message because you are subscribed to the Google
>> Groups "symfony developers" group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/symfony-devs?hl=en
>>
>
>  --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to