On Sat, Jul 4, 2015 at 1:42 AM, Peter of the Norse <[email protected]> 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 [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/CAFkDaoTHDBgK2v5Po09cShjQt7VoipA50BcoqawP6MymMmk1uQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
