On Tue, Jun 12, 2012 at 7:16 PM, Luke Plant <l.plant...@cantab.net> wrote:
>
> = Option 1: Leave things as they are, just document the problem. This
> was the least popular view on django-core.
>
> = Option 2: Deprecate Meta.exclude, but still allow a missing
> Meta.fields attribute to indicate that all fields should be editable.
>
> The policy here is essentially this: if any fields the model are
> sensitive, assume all are potentially, and require whitelisting, not
> blacklisting.
>
> = Option 3: Make the 'Meta.fields' attribute a required attribute, which
> must list all the model fields that should be editable. Without it,
> ModelForms would not work at all.
>
> This also means deprecating Meta.exclude (it's redundant once you are
> saying that all fields should be explicitly whitelisted).
>
What about a fourth option:
= Option 4: Make the 'Meta.fields' attribute required, but allow a
semaphore value ("__all__"?) that enables the insecure shortcut. We
can plaster it with warnings in the docs, which people will inevitably
check when the error pops up, "Meta.fields is required." There are
clearly some use cases where the maintenance burden of whitelisting
all fields is just not worth it and people will resort to hacks if we
hamstring the current behavior. It also gives an upgrade path for
people who would otherwise need to rearchitecture their applications
if the Meta.fields attribute suddenly became required. (I can imagine
models with hundreds of fields, or worse, dynamically generated
fields.)
Like Carl Meyer, I don't think Django's goals should be to protect
developers from themselves, but I agree that it is important that the
path of least resistance be secure in all areas. There is considerable
value in "A form that is automagically scaffolded from a Model" above
and beyond "A form that does default
model-field-type-to-form-field-type mappings" which is what ModelForms
will become under options 2 and 3. So long as that is an explicit
choice, I don't think there is too much harm in letting people do that
if they want to. In fact, the reason I consider Option 1 viable is
precisely because I consider the creation of a ModelForm to be
precisely that kind of choice, but I can see how having the default be
include-all is a problem.
In summary:
+0 on option 1. Making a ModelForm is already a choice to expose a
model directly.
-1 on option 2. Default is still insecure, and Meta.exclude has use cases.
+0 on option 3. It's like my option 4, but requires [for field in
Model._meta.fields] hackery to work around.
+1 on option 4. Auto-generated fields are useful, and this allows an
explicit opt-in.
Best,
Alex Ogier
--
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.
