id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 23482 SingleObjectMixin.get_object() should allow lookup by BOTH pk and slug Jon Dufresne nobody "Using generic views such as DetailView. Problem: I do not want to use the object PK as the only differentiating URL component, as it would allow users to brute force guess all URLs and gain knowledge of all objects. In my application, users have permission to view individual objects, but letting users know a complete list of all objects is undesirable. First thought, use a non-sequential slug. The slug could be based on the name of the object. However, the obvious source of the slug is not necessarily unique. Two objects can have identical names and this is OK for the object. I'd prefer to avoid additional overhead of calculating a unique slug. Next thought, append the PK to the name to generate the slug: -. This works as a unique slug, but has the drawback that a newly created object cannot create a slug until *after* the save when the `auto_increment` kicks in. Next thought, keep the slug as non-unique, but use both the slug and PK in the URL. So the slug would remain the name, and the URL would contain: `/-/`. Then look up the object by *both* the slug and the PK. This solves: * URLs aren't brute force guessable without first knowing the object you want to lookup * It is OK that the slug is not unique, the URL is. * URLs are prettier than a simple PK as the slug is more friendly to humans * The slug can be generated before save without a database hit However, the default implementation of `SingleObjectMixin.get_object()` uses *either* the PK or the slug, in that order, but not both. I am suggesting that it be modified to use both fields if they are both available. This would be as simple as changing the `elif slug is not None:` from `elif` to an `if` (with some minor cleanup for error checking and tests). If this change is agreeable, I would be happy to create a pull request that solves this problem. (I realize I can implement this in my own views, and will if I need to, but I thought this would be nice built-in.)" New feature closed Generic views dev Normal fixed Ready for checkin 1 0 0 0 0 0