Re: Encrpting urls to hide PKs

On Thu, May 12, 2011 at 12:29 AM, Wesley Childs wrote: > Why cant you do something like this to avoid exposing data if people are > guessing primary keys > > if request.user == Users.objects.get(id=pk-url): > Show data > Else: > raise 404 or redirect to home page > > The above requires

Re: Encrpting urls to hide PKs

Why cant you do something like this to avoid exposing data if people are guessing primary keys if request.user == Users.objects.get(id=pk-url): Show data Else: raise 404 or redirect to home page The above requires a logged in a user but you get the idea of not allowing people to start

Re: Encrpting urls to hide PKs

On May 10, 2011, at 4:02 PM, "Cal Leeming [Simplicity Media Ltd]" wrote: > Sean, are you suggesting that the OP rely on base36 encoding for security? > Please tell me you are joking. No not at all, I thought he stated this does not have to be secure. If it does, then yeah my code is a bad

Re: Encrpting urls to hide PKs

Sean, are you suggesting that the OP rely on base36 encoding for security? Please tell me you are joking. On 10/05/2011 15:32, Sean Brant wrote: Sorry I think I only responded to the original poster. >>> from django.utils.http import int_to_base36, base36_to_int >>> int_to_base36(1

Re: Encrpting urls to hide PKs

rather than embedding the confirmation ID in the URL; you can use session messages to pass the ID to the confirmation page view check out some examples here http://www.djangobook.com/en/beta/chapter12/ Regards, Bedros On May 10, 7:32 am, Sean Brant wrote: > Sorry I think I only responded to

Re: Encrpting urls to hide PKs

Sorry I think I only responded to the original poster. >>> from django.utils.http import int_to_base36, base36_to_int >>> int_to_base36(123) '3f' >>> base36_to_int('3f') 123 Sean -- You received this message because you are subscribed to the Google Groups "Django users" gro

Re: Encrpting urls to hide PKs

Some interesting stuff here. The short URL generator looks interesting. But yes, I appreciate the thoughts about security. Horses for courses and all that. Cheers ALJ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send

Re: Encrpting urls to hide PKs

Just to be clear, the issue I was referring to, was to not trust the data sent by the client. I.e. if you are allowing the user to access an object in the database, and not enforcing any restrictions other than client side UI, then this is bad. This topic spreads wa long cookies and

Re: Encrpting urls to hide PKs

If you are looking for a quick and easy way to encrypt the URLs, why not create some Middleware which encrypts/decrypts them on the fly with a secret string from settings? Although, the URLs are going to look ugly as sin, and I wouldn't recommend this if you want decent SEO lol. Remember you

Re: Encrpting urls to hide PKs

On Mon, May 9, 2011 at 8:15 AM, Brian Bouterse wrote: > In the name of not trusting any data coming from the client, one way that > IBM uses often is called continuations. I thought they were called cookies? > Basically you keep all data on the > server, and only give the client an identifier of

Re: Encrpting urls to hide PKs

On May 9, 2011, at 11:43 AM, ALJ wrote: > I was really looking for something lightweight. I didn't really want > to have to change the model structure to include a UUID ... although I > realise that this seems to way to go. I really just wanted to avoid > any 'opportunistic' attempts at extractin

Re: Encrpting urls to hide PKs

There's no need to change your models to add UUIDs. You can just store a dict of UUID-to-primary key values in the session data. -- 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.

Re: Encrpting urls to hide PKs

I was really looking for something lightweight. I didn't really want to have to change the model structure to include a UUID ... although I realise that this seems to way to go. I really just wanted to avoid any 'opportunistic' attempts at extracting the data. The data itself isn't critical and not

Re: Encrpting urls to hide PKs

In the name of not trusting any data coming from the client, one way that IBM uses often is called 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

Re: Encrpting urls to hide PKs

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

Re: Encrpting urls to hide PKs

Take a look at django-registration app. With slight modification it should satisfy your requirements. For URL encryption, you can generate some sort of UUID and save in your database that such UUID corresponds to given profile PK. django-registration uses such urls for email confirmation. On Mon,

Encrpting urls to hide PKs

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 conta