Semi-devil's-advocate suggestion: Replace the management form with a
management field, a hidden field with
name = "__manage__%s" % (formsetname)
and
value="x"
Then instead of taking the number of forms from a field on a management form,
we can just take the accumulated length of the management field (which would be
returned as an array). This also offers a better solution to the checkboxes-
only-form problem, I think.
Do we use the management form for anything other than counting forms in the
formset?
Shai.
On Saturday 06 June 2015 20:11:03 Marc Tamlyn wrote:
> I believe the complaint is mostly that an invalid formset will raise a 500
> whereas an invalid form (should) never. There was a patch to display an
> error if not. My complaint is that this error can only occur if the dev has
> rendered the form by hand missing the management form. It's likely they
> would also miss the non form error output this way and so the end result is
> we display back empty forms to the user with no useful error event though
> they filled in values. This is hard to debug and bad ux - a 500 is better.
>
> Equally, every time a security crawler posts an empty body to a page
> triggering a 500 is irritating noise. We don't report invalid forms as 500s
> either...
>
> This brought up the question of whether the management form is needed at
> all.
>
> Unrelated arguments: It also streamlines testing user formsets massively,
> and significantly reduces the complexity of js to add more forms.
>
> Marc
>
> On 6 Jun 2015 17:00, "Florian Apolloner" <[email protected]> wrote:
> > What about instead of trying to guess the forms from the input, just fix
> > the one condition which causes the error and return 0 as totalformcount +
> > an error marker to reraise the error in clean of the modelform?
> >
> > On Friday, June 5, 2015 at 11:29:21 AM UTC+1, Patryk Zawadzki wrote:
> >> Hi folks,
> >>
> >> I've talked to Marc about fixing the case where a formset will raise
> >> an uncaught ValidationError when instantiated with a missing or broken
> >> management form. This has caused us great pain when dealing with
> >> vulnerability scanners that tend to POST random crap to each endpoint
> >> they find as it means formsets—unlike forms—are not safe to
> >> instantiate with untrusted data.
> >>
> >> Now wrapping each and every formset instance in a try/except block and
> >> having to manually handle the fallback case is not fun. But as Marc
> >> pointed out, forgetting a management form is one of the most common
> >> pitfalls people run into when dealing with formsets.
> >>
> >> Therefore I propose making the management form optional. The only case
> >> that requires an explicit TOTAL_FORMS variable are forms that consist
> >> of nothing but checkboxes (as unchecked checkboxes are not included in
> >> POST data). In other cases (including all ModelFormSets as they always
> >> contain a hidden PK field) we can deduct the number of submitted forms
> >> from the data itself.
> >>
> >> Ideally I would get rid of the management form entirely and document
> >> that a form that is nothing but checkboxes is an unsupported case and
> >> that a workaround would be to include an extra hidden field. Honza may
> >> or may not kill me for suggesting that.
> >>
> >> For now, I would like to make the formset optional and document the
> >> cases where you need to include it. If included, it would take
> >> precedence to keep the existing deployments working.
> >>
> >> Thoughts?
> >>
> >> --
> >> Patryk Zawadzki
> >> I solve problems.
> >>
> > --
> >
> > You received this message because you are subscribed to the Google Groups
> > "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to [email protected].
> > To post to this group, send email to [email protected].
> > Visit this group at http://groups.google.com/group/django-developers.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/django-developers/de9e5a03-7f14-42e8-bf
> > 76-9405440ecf94%40googlegroups.com
> > <https://groups.google.com/d/msgid/django-developers/de9e5a03-7f14-42e8-
> > bf76-9405440ecf94%40googlegroups.com?utm_medium=email&utm_source=footer>
> > .
> > For more options, visit https://groups.google.com/d/optout.
