Hi All, I can see two separate (but related) problems that need to be solved:
1. Ensure that sensitive fields are not accidentally exposed to users (e.g when a database model is updated to include one), and 2. Provide a means to confirm whether the fields as rendered and submitted exactly match the intent of the form. This is my proposal for problem 1: Add an "is_sensitive" or similarly named boolean attribute to model fields. This field would be False by default and would be set to True for fields that contain sensitive data e.g: class Article(models.Model): text = models.TextField() secret_notes = models.TextField(is_sensitive=True) Now a ModelForm would by default exclude any field that is marked as sensitive, unless it is explicitly included via the "fields" attribute. The advantage of the above is that it allows mechanisms other than Forms to enforce rules associated with sensitive data and could potentially be double checked while being rendered as well. For developers who don't care about sensitive data, nothing changes, unless the is_sensitive attribute is made True by default (which would be a pain). Regards, Atul On 14 June 2012 10:18, Carl Meyer <[email protected]> wrote: > On 06/13/2012 06:12 PM, Doug Blank wrote: > > On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer <[email protected]> wrote: > >> On 06/13/2012 02:55 PM, Peter wrote: > >>> Can I throw in option 5: > >>> > >>> We leave ModelForms as they are, but emit a warning if you only > >>> partially render the form? > >>> > >>> I'm not sure how feasible this is, but presumably we could keep track > of > >>> which fields have been rendered for a given form instance? > >>> > >>> That way, if you render the whole form ( {{ form.as_p }} ) you'll see > >>> your new sensitive field appear in the page. If you manually render the > >>> form, you'll get a warning. > >> > >> I've thought about this. The main problem is that the implementation is > >> quite difficult in practice: at what point do you perform the check? > >> There isn't any such thing as an "ok, I think I'm all done rendering > >> this form now, tell me if I did it right" hook. > > > > I, too, was thinking about this kind of solution. In fact, it came up > > for me the other day because I had forgotten to exclude a field that I > > did not have on the form, and so the value ended up getting wiped out > > when I saved. So, perhaps a solution that prevented others from adding > > fields could also be a solution that checked to make sure that the > > form was editing all fields it should be. > > > > What about a {% validate %} tag in the form which would do a runtime > > check to make sure that all non-excluded fields had been rendered? > > Yeah, this would be a cleaner way to implement the check. I'd like to > see it proved out as a third-party add-on before discussing it for core. > One of the unresolved issues in my mind is what it should actually _do_ > if you haven't rendered all the fields on the form (blow up in DEBUG > mode only? Just a call to warnings.warn?). > > And since it's opt-in (and easy to forget or not bother with) I'm not > sure that by itself it's a satisfactory solution to the original problem > of implicit Meta.fields. > > Carl > > -- > 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. > > -- 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.
