On 13 kesä, 20:58, Carl Meyer <[email protected]> wrote:
> > 2. The fix doesn't actually fix the issue for all cases. You are still
> > allowed to use the same form in a way that renders additional fields
> > based on user permissions or if the user is authenticated. If you
> > reuse the same form in multiple views for example, or your template
> > contains some logic to add/remove fields dynamically.
>
> I don't see how this is relevant. Dynamic addition or removal of fields
> is an uncommon edge case; it's way beyond the "insecure defaults" issue
> and well into "if you're doing advanced stuff, you just have to know
> what you're doing" territory.
The point is the same form with the same fields can be used in
multiple places. There is no need for dynamic addition and removal of
fields in Python code. The dynamism is in which fields to display -
not which fields the form contains. You render only field1, except for
superusers you render field1 and field2. Thus, the fields = ('field1',
'field2') in the form's meta doesn't do the security restriction you
want for this case - the place to do the restriction is in the form
init call:
if user is superuser:
form = MyModelForm(request.POST, allowed_fields=('field1',
'field2'))
else:
form = MyModelForm(request.POST, allowed_fields=('field1',))
Part of the problem is that it is easy to think that if you don't have
the fields in the HTML form, then the user can't edit the fields.
It would be useful to know how many projects contain ModelForms with
no field restrictions, and only display a subset and always the same
subset of the fields.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django 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/django-developers?hl=en.
