Hi Tom, my main goal is to avoid that the access to the users table by anything else other than the authentication module. I understand that writing the app correctly and filtering the input, etc... will do the same, but it's just another layer of security.
I'll take a look to the DB routers and how this can be implemented. Thanks for your reply. Cheers, Isaac 2013/1/14 Tom Evans <[email protected]> > On Sun, Jan 13, 2013 at 5:05 PM, Isaac Perez > <[email protected]> wrote: > > Hi guys, > > > > I'm creating a new app and I'd like to know how would be the best way to > > implement the principle of least privilege. > > At the moment the DB has 5 users: > > > > 1 is the root user for the DB (which I don't want it to be used by the > > webapp) > > 1 has read access to the data fields > > 1 has write access to the data fields > > 1 has read access to the users table > > 1 has write access to the users table > > > > What I intend to achieve is that if in any occasion we've got a sql > > injection for whatever the reason, the access to the DB from the app form > > will be as limited as possible. > > > > If using python directly I would create a DB connection for each > > functionality so they use the right DB user and have the right > permissions. > > > > In Django, though, as you have to configure the default DB access in the > > settings and it has to sync, etc... I'm not sure what will be the best > way > > to implement that splitting of privileges. > > > > I've configured the 5 connections in the settings but not sure how to > best > > use them for the different functions of authenticate, read and write from > > the DB. > > > > Any ideas? > > > > Hi Isaac > > Personally I think this is overkill, but you can achieve exactly what > you want by using DB routers to allow Django to select the right DB > connection to use at the right time. > > However, what's the point? If your DB router correctly tells Django to > use the "data write" DB handle when saving data fields on an object > loaded from the "data read" DB handle, then it would do so whenever > asked to save an object. So saving objects would always use the write > handle. > > In effect, by separating out read and write handles, all you are > protecting against is Django accidentally generating a query to modify > your DB when it is attempting to generate a query to read from your > DB. > > Cheers > > Tom > > -- > 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.
