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
-~----------~----~----~----~------~----~------~--~---

Reply via email to