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.