HI!
I don't know if this is a viable solution, but, however, i would like to say
it.
in your form add this:
protected function doUpdateObject($values)
{
parent::doUpdateObject($values);
$this->getObject()->setId($this->getOption('id'));
}
If, you do that, you can add in your code something like:
$this->form = new editContactsForm($contact_object, array(
'id' => $contact_object->getId()
));
No matter what id will modify the client, the id that will be kept into the
database, would be the id you provide in the form option.
in the constructor of the form you could override, and add something like
// not tested, not verified, never implemented yet
public function __construct($object = null, $options = array() ... )
{
parent::__construct($object, $options);
if ( $object instanceof $this->getModelName() )
{
if (false === $object->isNew())
{
$this->setOption('id', $object->getId());
}
}
}
Alecs
On Fri, May 28, 2010 at 8:37 PM, Stephen Melrose <[email protected]>wrote:
> First time I've given something back to symfony. Glad to see the system
> works. Cheers for all the help.
>
>
> On 28 May 2010, at 17:57, Kris Wallsmith <
> [email protected]> wrote:
>
> I've committed the patch and will release 1.3.5 and 1.4.5 shortly. Thanks
> for everyone's input.
> Kris
>
> --
>
> *Kris Wallsmith* | Release Manager
> <[email protected]>[email protected]
> Portland, Oregon USA
>
> <http://twitter.com/kriswallsmith>http://twitter.com/kriswallsmith
>
> On May 28, 2010, at 3:43 AM, Stephen Melrose wrote:
>
> I know that. And Kris proposed a fix for that. My answer was about the
>> mass-assignment problem and the attr_accessible thing Rails has.
>>
>
> My apologies, I misunderstood.
>
> I can also confirm the patch works and solves the problem.
>
>
> On 28 May 2010 11:26, Fabien Potencier <<[email protected]>
> [email protected]> wrote:
>
>>
>> On 5/28/10 9:31 AM, Stephen Melrose wrote:
>>
>>> If it was easy as just removing the ID field, I wouldn't have bothered
>>> posting this.
>>>
>>> But a lot of the Propel validators require the ID to be in the values
>>> array to validate against. So if you remove it, they stop working.
>>>
>>
>> I know that. And Kris proposed a fix for that. My answer was about the
>> mass-assignment problem and the attr_accessible thing Rails has.
>>
>> Fabien
>>
>>
>>
>>>
>>>
>>> On 28 May 2010, at 08:19, Fabien Potencier
>>> < <[email protected]>
>>> [email protected]> wrote:
>>>
>>> On 5/28/10 9:04 AM, Don Pinkster wrote:
>>>>
>>>>> My 2 cents:
>>>>>
>>>>> Why don't we use something as attr_accessible in Ruby on Rails?
>>>>> This way you can specify which attributes may be set with mass
>>>>> assignment ($form->bind()); and need to be set with explicit setters:
>>>>> $form->setValue()?
>>>>>
>>>>
>>>> We don't have mass-assignement problems with symfony, just remove the
>>>> fields you don't want the user to modify.
>>>>
>>>>
>>>>> Now I write this, isnt this wat $this->useOnly() is meant for?
>>>>>
>>>>
>>>> Exactly. You can also just unset() fields.
>>>>
>>>> Fabien
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: "Kris Wallsmith"< <[email protected]>
>>>>> [email protected]>
>>>>> Sent: Friday, 28 May, 2010 07:17
>>>>> To: "symfony developers"< <[email protected]>
>>>>> [email protected]>
>>>>> Subject: [symfony-devs] Re: Potential Flaw in the Form Framework [1.4]
>>>>>
>>>>> I've attached a patch to the ticket for review. Please comment.
>>>>> <http://trac.symfony-project.org/ticket/8639>
>>>>> http://trac.symfony-project.org/ticket/8639
>>>>>
>>>>> Thanks,
>>>>> Kris
>>>>>
>>>>> On 10 May, 12:08, Stephen Melrose<[email protected]> wrote:
>>>>>
>>>>>> It's not that simple Russ.
>>>>>>
>>>>>> Where do you perform the check that they are allowed to access/save an
>>>>>> object of a certain ID?
>>>>>>
>>>>>> I personally have always checked the object after I've taken it from
>>>>>> the
>>>>>> route and before I've passed it to the form. After I've done that, I
>>>>>> don't
>>>>>> expect the object to magically be transformed into another record,
>>>>>> a.k.a.
>>>>>> something they're not allowed to access, and I bet the vast majority
>>>>>> of
>>>>>> symfony developers don't either.
>>>>>>
>>>>>> Your point is valid and one I've agreed with throughout this thread,
>>>>>> if
>>>>>> you're restricting what a user can edit, you need to make sure you
>>>>>> safe
>>>>>> guard your code properly, and that's something I didn't do purely
>>>>>> because I
>>>>>> didn't expect the scenario I've detailed to occur, and to be honest,
>>>>>> nor
>>>>>> should it.
>>>>>>
>>>>>> The ID is passed as a hidden field (for whatever reason), but I
>>>>>> don't expect
>>>>>> the PK to be changed. How often would you actually edit a PK?
>>>>>>
>>>>>> I'm simply arguing the PK should be read only be default.
>>>>>>
>>>>>> On 10 May 2010 20:01, Russ<[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Personally I always check if the user has credentials to edit the
>>>>>>> object anyway and I couldn't give a monkeys if they change the id
>>>>>>> using Firebug or whatever as long as it's to one they have access to.
>>>>>>> If not, they'll get a nice 403 response either way.
>>>>>>>
>>>>>>
>>>>>> The way I see it, editing the ID using Firebug or some other method
>>>>>>> would be just the same as if they opened that object up for editing
>>>>>>> in
>>>>>>> the first place... As long as they are allowed to, then so be it.
>>>>>>>
>>>>>>
>>>>>> On May 10, 12:16 pm, Stephen Melrose<[email protected]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>
>>>>>> We have discovered what could be a potential flaw in the form
>>>>>>>> framework. The reason I'm discussing this here is because I'm in
>>>>>>>> mixed
>>>>>>>> feelings as to whether this is actually bug or not, or rather poor
>>>>>>>> implementation on our part. Either way, I'm also saying this flaw
>>>>>>>> should be safe guarded against.
>>>>>>>>
>>>>>>>
>>>>>> We discovered that a malicious user can use the forms generated by
>>>>>>>> the
>>>>>>>> form framework to edit content they shouldn't be able to.
>>>>>>>>
>>>>>>>
>>>>>> They do this by replacing the primary ID in the hidden form field
>>>>>>>> with
>>>>>>>> that of the record they want to edit. When they hit save, the
>>>>>>>> validation is run, and the Object is updated with the new ID, so
>>>>>>>> when
>>>>>>>> the save() is called, the other row is updated.
>>>>>>>>
>>>>>>>
>>>>>> Now, if we (as in developers) want to restrict editing of content for
>>>>>>>> certain users, then it is our responsibility to make sure we put
>>>>>>>> safe
>>>>>>>> guards in place. I'm not arguing this fact.
>>>>>>>>
>>>>>>>
>>>>>> The reason I believe this to be a problem is how users will actually
>>>>>>>> guard their code. Most people (including myself) run all the safe
>>>>>>>> guard checks before the Object is passed into the Form on
>>>>>>>> construction. I don't then expect the POST data to override the
>>>>>>>> primary key of the Object on save. Infact, I can't think of an
>>>>>>>> instance I would ever want this to happen.
>>>>>>>>
>>>>>>>
>>>>>> I therefore propose that some sort of restriction/block is put in
>>>>>>>> place by default that stops the PK of an Object being altered on
>>>>>>>> bind().
>>>>>>>>
>>>>>>>
>>>>>> Thoughts?
>>>>>>>>
>>>>>>>
>>>>>> Stephen Melrose
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>>>> If you want to report a vulnerability issue on symfony, please
>>>>>>>> send it to
>>>>>>>>
>>>>>>> security at <http://symfony-project.com/>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]>[email protected]
>>>>>>>> To unsubscribe from this group, send email to
>>>>>>>> <symfony-devs%[email protected]>
>>>>>>>> [email protected]
>>>>>>>> <symfony-devs%2bunsubscr...@google
>>>>>>>> <http://groups.com/>groups.com>
>>>>>>>> For more options, visit this group athttp://
>>>>>>>>
>>>>>>> <http://groups.google.com/group/symfony-devs?hl=en>
>>>>>>> groups.google.com/group/symfony-devs?hl=en
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>> If you want to report a vulnerability issue on symfony, please send
>>>>>>> it to
>>>>>>> security at <http://symfony-project.com/>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]>
>>>>>>> [email protected]
>>>>>>> To unsubscribe from this group, send email to
>>>>>>> <symfony-devs%[email protected]>
>>>>>>> [email protected]
>>>>>>> <symfony-devs%2bunsubscr...@google
>>>>>>> <http://groups.com/>groups.com>
>>>>>>> For more options, visit this group at
>>>>>>> <http://groups.google.com/group/symfony-devs?hl=en>
>>>>>>> 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 <http://symfony-project.com/>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]>
>>>>>> [email protected]
>>>>>> To unsubscribe from this group, send email to
>>>>>> <symfony-devs%[email protected]>
>>>>>> [email protected]
>>>>>> For more options, visit this group
>>>>>> athttp:// <http://groups.google.com/group/symfony-devs?hl=en>
>>>>>> groups.google.com/group/symfony-devs?hl=en
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> If you want to report a vulnerability issue on symfony, please send it
>>>> to security at <http://symfony-project.com/>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]>
>>>> [email protected]
>>>> To unsubscribe from this group, send email to
>>>> <symfony-devs%[email protected]>
>>>> [email protected]
>>>> For more options, visit this group at
>>>> <http://groups.google.com/group/symfony-devs?hl=en>
>>>> 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 <http://symfony-project.com/>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]>
>> [email protected]
>> To unsubscribe from this group, send email to
>> <symfony-devs%[email protected]>
>> [email protected]
>> For more options, visit this group at
>> <http://groups.google.com/group/symfony-devs?hl=en>
>> 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 <http://symfony-project.com>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]>
> [email protected]
> To unsubscribe from this group, send email to
> <[email protected]>
> [email protected]
> For more options, visit this group at
> <http://groups.google.com/group/symfony-devs?hl=en>
> 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 <http://symfony-project.com>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]>
> [email protected]
> To unsubscribe from this group, send email to
> <[email protected]>
> [email protected]
> For more options, visit this group at
> <http://groups.google.com/group/symfony-devs?hl=en>
> 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]<symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
Have a nice day!
Alecs
Certified ScrumMaster
P.S. If you are on a list, please don't contact me privatelly, unless i have
allowed to. Further messages will be ignored.
There are no cannibals alive! I have ate the last one yesterday ...
I am on web: http://www.alecslupu.ro/
I am on twitter: http://twitter.com/alecslupu
I am on linkedIn: http://www.linkedin.com/in/alecslupu
Tel: (+4)0722 621 280
--
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
