> On Jul 2, 2015, at 7:46 PM, Carl Meyer <[email protected]> wrote: > >> So what? It’s quite likely that whoever is editing this row of the >> database, also has permissions to edit the other rows as well. There’s >> no reason for them to go through the hassle of manually editing a hidden >> field when they can go to a different page and edit it there. > > That's a bad answer. It's common in many systems for a user to have > access to edit some records in a table but not others (this is often > known as "object-level permissions"). If it was really possible to edit > any row in the table by just manually editing the PK hidden field, that > would be a serious security flaw in formsets. > > But it's not. Whatever queryset you pass to the model formset limits the > available rows for editing. The end user can edit the PK to refer to any > item in that queryset, but not any item in the table. > >> In general, primary keys are not security flaws. While it’s a good idea >> to hide them from front-end pages, that’s mostly because they make URLs >> hard to read. I have heard that you don’t want to use them publicly, >> because your competitors can use them to gauge your success, but that’s >> the kind of “Nice Problem to Have” that can wait until you’re bigger. > > Exposing primary keys themselves (e.g. in URLs) is not necessarily a > security flaw. Exposing a primary key in a hidden field that can be > edited to change a form to edit any row in a table often would be a > serious security flaw.
You can’t have it both ways. Either exposing the PK is a security flaw or it isn’t. It’s just as easy for nefarious n’er-do-wells to edit the form’s URL as a hidden field. In either case, if you are using object-level permissions, more checks (not made automatic in Django) are necessary. Having the ID passed as a parameter doesn’t necessitate, hinder, or alleviate running these checks. If you can come up with a method that associates form data with a database row that doesn’t involve the PK, I would love to know. Keep in mind that most tables only have the one unique identifier. Peter of the Norse [email protected] -- You received this message because you are subscribed to the Google Groups "Django users" 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-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/F9FAB5F9-F4EA-45C8-834A-FB39B26F4B63%40Radio1190.org. For more options, visit https://groups.google.com/d/optout.
