I have found a solution to prevent changes of some values with usage
of admin generator:
1. In the generator.yml the used form class is defined. By default is
is sfGuardUserForm.
Build your own class which is extending the default class and
change the generator.yml
...
form:
class: BackendUserForm
...
2.
Override the bind method and call the parent's one in it.
But before you call it you can reset some values to it's default
values.
...
public function bind(array $taintedValues = null, array
$taintedFiles = null)
{
$taintedValues["username"] = $this->getDefault("username");
return parent::bind($taintedValues,$taintedFiles);
}
...
3. For a better usability define those values as readonly in the
generator.yml.
...
edit:
title: Editing User "%%username%%"
fields:
username:
attributes:
readonly: readonly
...
regards,
Michael
On 29 Jul., 16:01, "mlu...@gmail.com" <mlu...@gmail.com> wrote:
> In my app i am using sfGuardPlugin. In the frontend it's not possible
> the change the user name of an existing user, that's OK of course.
>
> But today I am working on the backend and I have seen there it's
> possible to change the user name.
> My first thought was to define the username as disabled in the
> generator.yml.
> But unfortunately html forms don't send disabled fields and so the
> save action results in a missing field.
> Than I made the username readonly, what worked in the first step. But
> if you change the username via firebug it's submitted and the server
> logic accepts it.
>
> So defining a field as readonly in generator.yml doesn't mean the
> serverlogic treats it as readonly. Just the HTML form field is
> readonly! This is ok to prevent editors to change fields they
> shouldn't change. But as far as WebAppSec is concerned it's the same
> as an editable field.
>
> Is there there a way to really define a field "not editable" in the
> admin generator?
>
> The only solution I see at the moment is to code everything in the
> backend myself and don't to use the admin generator at all. I see a
> high risc in case of a lazy XSS attack.
>
> What do you think?
>
> regards,
>
> michael
--
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 users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
