Hi Luke,

Thanks for identifying this issue and continuing to push for a resolution.

On 06/12/2012 05:16 PM, Luke Plant wrote:
> == Option 1: This is the least secure, but most convenient - you have
> several ways to specify which fields should be editable, you can use
> whichever you like. "We're all consenting adults here".
> 
> An argument in favour of keeping this is if we don't, people will just
> use 'fields = [f.name for f in MyModel._meta.fields]' anyway.
> 
> == Option 2: the retains some of the convenience of option 1, while
> encouraging more careful handling of "sensitive" models.
> 
> == Option 3: the most secure, the least convenient. You have to list all
> fields for every ModelForm (except for cases of sub-classing forms,
> where the base class's Meta.fields would still work, of course).
> "Explicit is better than implicit".
> 
> The option doesn't make an assumption that models are either 'sensitive'
> or not. It is also more consistent than option 2: if you add a field to
> a model, you know that if it is meant to be publicly editable, you have
> to edit the ModelForms to add it, and if it is not meant to be editable,
> you don't, because the list is always "opt in".

I favor option 3; I think the Rails issue should have taught us that
exposing database data to modification by remote users is something that
deserves to always be done explicitly.

I think the most pressing issue is the behavior of UpdateView, because
it allows a naive developer to bypass the forms layer entirely (since it
automatically constructs a ModelForm subclass if given a model). As
others have pointed out, our situation in general is somewhat better
than Rails because we have the explicit Form layer; even if a developer
constructs a ModelForm with implicit fields they at least have to think
about the fact that this form should be responsible for data validation.
But this is not true with UpdateView; I think UpdateView is actually a
very close parallel to the Rails issue.

So while I favor option 3 for ModelForms themselves, I also think that
even if this discussion should end up rejecting that, we should still at
the very least require an explicit "fields" parameter for UpdateView.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to