On Sat, Jul 4, 2015 at 1:42 AM, Peter of the Norse <rahmc...@radio1190.org> wrote: > 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.
the easiest way to make forget PKs a non-issue is to never do things like: myobj = MyModel.objects.get(pk=pk) instead, do things like: myobj = get_object_or_404(request.user.accessible_obj_set, pk=pk) where the 'accessible_obj_set' is either a reverse foreign key, or some method that returns a queryset with apropriate filters to return only the rows that a given user can access. > 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. there are many fans of using UUIDs as primary key. myself, i use them for any user-visible record when there might be several instances of the same code. this way i can merge or split datasets without changing user-visible references. -- Javier -- 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. 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/CAFkDaoTHDBgK2v5Po09cShjQt7VoipA50BcoqawP6MymMmk1uQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
