On Feb 3, 2008 6:37 AM, Julien <[EMAIL PROTECTED]> wrote: > I found a trick that works for my use case. I just don't execute if > it's not a SELECT request. I do the test like so:
Things your filter doesn't catch: * PostgreSQL's table-creating SELECT INTO statement. * Any "query" which consists of multiple statements separated by semicolons (e.g., "SELECT * from foo; DROP TABLE auth_user;"). * etc., etc. Your database already knows how to handle a read-only user. Either set up a separate settings file and run the client-facing part of your site on that (most secure) or have this method obtain its own separate database connection as a read-only user (not as good, but still decent). Trying to invent a security system which prevents any and all data-altering queries will almost certainly end in pain and suffering, especially when you already have easy access to a proven system that does the same thing. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
