In the name of not trusting any data coming from the client, one way that IBM uses often is called continuations<http://en.wikipedia.org/wiki/Continuations>. Basically you keep all data on the server, and only give the client an identifier of that data. This typically enforces a server-side state machine that ensures what a user can and can't do with the application from a given state.
This is not exactly what is being discussed here, but it is near it in topic, so I thought I would mention it. Brian On Mon, May 9, 2011 at 8:59 AM, Cal Leeming [Simplicity Media Ltd] < cal.leem...@simplicitymedialtd.co.uk> wrote: > To be honest, I'd be careful when using this approach. > > If you are intending on hiding the PKs, as a way to stop people hitting PKs > they shouldn't be able to hit, then this means your security model is flawed > from the ground up. > > However, if you are doing it to stop PKs from being leaked, then this is > fine. > > Remember the number 1 rule in security.. NEVER TRUST THE CLIENT!!! > > On Mon, May 9, 2011 at 1:24 PM, ALJ <astley.lejas...@gmail.com> wrote: > >> I have a form that I use to collect contact information from >> unregistered users. When they submit the form I want to redirect to a >> confirmation page (as the Django documentation suggests). However, >> instead of a generic page, I wanted to include the information that >> they have submitted and the contact details of the person for their >> area. I was also thinking that I could include the current status of >> their enquiry. Therefore they could perhaps use the same link to come >> back to check the status of their query. >> >> Given that, is there a best practice pattern for handling this >> situation? I have a quick demo where the URL is: >> >> http://www.mydomain.com/contact/confirmation/1234 >> >> ... where '1234' is the pk for the query. Obviously I would want to >> encrypt the pk in this case, otherwise someone could just use the pk >> to trawl through the database. >> >> Are there any default ways of encrypting django urls? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-users@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- Brian Bouterse ITng Services -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
