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] < [email protected]> 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 <[email protected]> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
