On 3/23/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-03-23 at 14:14 +1100, Matthew Flanagan wrote: > > On 3/23/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > > > > > > > > On 23-Mar-07, at 6:22 AM, Mike Stoddart wrote: > > > > > > > For example, I have a web app that defines a number of models. People > > > > use the web interface but I also want to write some Python utils that > > > > access the same database and data using the same models as standalone > > > > applications. > > > > > > as i am very fond of saying - django is nothing but python > > > > > > > Yes, but Django auth is really only for web apps and can be easily > > bypassed in commandline scripts, for example: > > > > $ python > > Python 2.4.4 (#1, Mar 21 2007, 14:34:56) [C] on sunos5 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> from myapp.models import SomeThing > > >>> for obj in SomeThing.objects.all(): > > >>> obj.delete() > > > > If the full Django api is available on the system then this kind of > > thing is difficult to prevent. > > The Django auth layer only applies to situations where you have a > concept of users inside a web request, so your statement is true, but > not really applicable. When code runs, it runs as a user on the system, > unrelated to users making web requests. If you wanted to control who was > permitted to run code that accessed the database, etc, you would do this > by setting up a number of database users and controlling access to the > settings.py files (remember that you can have more than one such file > that are all the same except for the database users they specify).
Yes, this is how I've handled this to a limited degree in the past. But doing anything like the Thread Locals User [1] stuff from the command-line is next to impossible. The only real way to do it effectively is to write a web service api that people can then write scripts for and still be authenticated in the way normal web users are. [1] http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser > > It's not trivially possible to say a particular *system* user only has > access to one model and not another because, as you mention, Django is > designed more around the web app model, so change privileges like that > are enforced by the framework itself, not by something outside of it. > You could enforce even this sort of access control, though: the database > user used by code accessing Django directly might only have update > privileges on a couple of tables and select (or no) privileges on > others, thereby enforcing database access restrictions. > > With sufficient motivation and caffeine, anything is possible. :-) > > Regards, > Malcolm > > > > > > -- matthew http://wadofstuff.blogspot.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
