2👍
I recently implemented this functionality in a project. It can be done by using automatically generated uuid’s. Django has a built-in model field for this, or you can use a slug field and give it a default value. Here is a quick example.
In your models.py file, import the uuid library and then set the default value of your slug field to be uuid.uuid4.
models.py:
import uuid
class Ticket(models.Model):
uuid = models.SlugField(default=uuid.uuid4, editable=False)
...
In urls.py, just use the uuid field as if it were a pk. Something like this:
url(r'^manager/tickets/(?P<uuid>[0-9a-z-]+)/?$', TicketDetail.as_view(), name='ticket-detail'),
In your detail, update, and delete views, you will need to make sure and set these two attributes so that Django knows which field to use as the slug:
slug_field = 'uuid'
slug_url_kwarg = 'uuid'
Then in your templates and whenever you need to retrieve an object for the kwargs, just use the uuid instead of the pk.
Note that in addition to this, you should also do all you can with permissions to block users from seeing other pages. You may be able to block certain accounts from viewing other peoples details. For instance, you could probably write a permissions mixin to check whether request.user matches up with the object that the view is handling.
tldr This is assuming that you have some kind of relation to a user on your Ticket
model:
class SameUserOnlyMixin(object):
def has_permissions(self):
# Assumes that your Ticket model has a foreign key called user.
return self.get_object().user == self.request.user
def dispatch(self, request, *args, **kwargs):
if not self.has_permissions():
raise Http404('You do not have permission.')
return super(SameUserOnlyMixin, self).dispatch(
request, *args, **kwargs)
Finally, stick it on to your view like this:
class TicketDisplay(LoginRequiredMixin, SameUserOnlyMixin, DetailView):
...
0👍
You will need to make user 1 have something that user 2 can not imitate.
Preferred way would be to use your existing auth methods and check if user accessing the page is allowed to do so.
If you don’t have registration on your site then you could generate some random string – secret
– and store it with the question. If ‘user’ has that secret
then he’s allowed.
This secret string can be stored in cookie or made a part of URL.
Storing it in a cookie has a drawback: if cookie is lost then nobody can access the page. Also user cannot access it from other browser.
Making it a part of url has another drawback: if someone else sees the link, he can access that page too. This could be bad if user’s software automatically reports likns he visits somewhere.
Combining these approaches has both drawbacks.
- [Answered ]-Limiting the number of displayed instances of a model in Django Admin
- [Answered ]-NoReverseMatch at Django
- [Answered ]-Many-to-many fields with intermediate tables must not be symmetrical
- [Answered ]-During django unittests, database remains empty