Hi Anssi, On 06/13/2012 12:08 AM, Anssi Kääriäinen wrote: > On 13 kesä, 02:16, Luke Plant <[email protected]> wrote: >> For the record, I brought up the issue initially, and favour the most >> secure of the options outlined below, but I'll try to summarise with as >> little bias as I can! > <SNIP> >> = 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. > > I support option 2. I will try to keep the reasoning part short. The > end of post is devoted to another idea. > > Here are the reasons why I think Option 3 isn't worth the trouble: > > 1. Users will learn to use fields = [f.attname for f in > Permission._meta.fields]. At that point we haven't gained anything in > security, but made modelforms less convenient to use.
No, even if some users do this we will still have gained quite a lot. There will always be some way for users to do whatever they like - this is Python, and that's a good thing. But it's critically different when the user must actively choose to circumvent a secure default, as opposed to Django making a risky default the obvious path for naive newbies. In any case, I think in actual fact only a small percentage of users will do this; for many ModelForms just specifying the desired fields will be simpler and easier. > 2. The fix doesn't actually fix the issue for all cases. You are still > allowed to use the same form in a way that renders additional fields > based on user permissions or if the user is authenticated. If you > reuse the same form in multiple views for example, or your template > contains some logic to add/remove fields dynamically. I don't see how this is relevant. Dynamic addition or removal of fields is an uncommon edge case; it's way beyond the "insecure defaults" issue and well into "if you're doing advanced stuff, you just have to know what you're doing" territory. > Yes, option 3 is a bit more secure than option 2, but I don't find the > cost-benefit ratio correct. It will still not protect users from this > admittedly easy to do security mistake. So, I am -0 to option 3. Option 3 is the only option that addresses the real problem, which is that the simplest and easiest way for a naive newbie to create a ModelForm sets them up for trouble. Asking for a solution that "protects users" is the wrong goal to begin with - there's always a way to be insecure if you want. Our responsibility as a framework is not to protect users, it's just to stop actively encouraging them to do the wrong thing. 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.
