On Tue, Jan 15, 2013 at 5:27 AM, Isaac Perez <isaac.perez.mon...@gmail.com> wrote: > In a few words what I want to protect from is that an sql query could be > passed in the main input text box and it could access other users passwords > or information.
this simply doesn't happen with modern client libraries, as long as you don't use user-provided text to build the SQL queries. SQL parameters are separated from the SQL command and can't change the command structure. > Also don't feel comfortable with the app having root access to all the DB if > it doesn't need it for it's main function, just in case. that's reasonable, root access isn't needed. but you do need SELECT, UPDATE, INSERT and DELETE if by 'all the DB' you want to further split between what's accessible to each user, you can use model managers to enforce some conditions to all querysets, making it very hard for an innocent bug to affect more than a single user. don't forget that there's two very different things understood as 'safety': protection against bugs and against malicious attack. strategies and mitigation are different for each one. failing to see the difference leads to overcomplicated schemes that raise the probability of nasty bugs -- Javier -- 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.
