I use django-guardian for object level permissions and it works surprisingly well
On Mon, Aug 7, 2017 at 4:59 AM, Antonis Christofides < anto...@djangodeployment.com> wrote: > Hello, > > This is a tricky issue and we need to start from the basics. You already > know the basics, but they bear repeating. (Related questions are relatively > common, which is why this is something like the third time I'm pasting this > information here). > > As you know, RDBMS's keep their own list of users and have sophisticated > permissions systems with which different users have different permissions > on different tables. This is particularly useful in desktop applications > that connect directly to the database. Web applications changed that. > Instead of the RDBMS managing the users and their permissions, we have a > single RDBMS user as which Django connects to the RDBMS, and this user has > full permissions on the database. The actual users and their permissions > are managed by Django itself (more precisely, by the included Django app > django.contrib.auth), using database tables created by Django. What a user > can or cannot do is decided by Django, not by the RDBMS. This is a pity > because django.contrib.auth (or the equivalent in other web frameworks) > largely duplicates functionality that already exists in the RDBMS, and > because having the RDBMS check the permissions is more robust and more > secure. I believe that the reason web frameworks were developed this way is > independence from any specific RDBMS, but I don't really know. > > So the canonical way of working is to have a single *database user* as > which Django logs on to the database, with full permissions on the database > (including permission to create and delete tables), and many *Django > users*, each one with different permissions. Typically only one Django > superuser is created. I call the superuser "admin", which I believe is the > common practice. > > You can probably do things differently, and maybe there exist custom > database backends that would allow you to switch the database user on > login, but if there's no compelling reason you should really stick to the > canonical way. > > So, I agree with you that, in theory, it would be more elegant (and more > robust and more secure) to do this thing at the db level, and that it is a > pity that Django and similar systems have moved this functionality from the > db to the app. However, as I said, without a compelling reason you should > really stick to the canonical way. The canonical way is more maintainable, > because it's widely used. It will be easier for other programmers to > understand what you are doing. Elegance of solution is not compelling > enough. A compelling reason would be, for example, if you also have a > desktop application that is controlled by the user and connects directly to > the database. > > Regards, > > Antonis > > Antonis Christofideshttp://djangodeployment.com > > > On 2017-08-07 09:43, guettli wrote: > > Hello this post is now four days old. I would like to hear from other > people. > > Something like: > > "I have no clue what you are talking about" or > "I understand your concerns, but I have no clue, too" or > "Thank you about talking about this, this raised my awareness" > > would make me happy. > > Thank you. > > Am Donnerstag, 3. August 2017 10:07:53 UTC+2 schrieb guettli: >> >> First I asked a similar question on the postgresql-general list. The >> discussion[1] has settled there. >> >> Now I would love the hear what you think. >> >> >> I am thinking about rewriting an existing application which uses PostgreSQL >> via Django. >> >> Up to now the permission checks are done at the application level. >> >> Up to now queries like: "Show all items which the current user is allowed to >> modify" result in complicated SQL and >> this leads to slow queries. >> >> Up to now there is one db-user and the application does the filtering of >> rows to prevent application users to see >> items which they are not allowed to see. >> >> I guess most web applications work like this. >> >> I would like to reduce the "ifing and elsing" in my python code (less >> conditions, less bugs, more SQL, more performance) >> >> One important intention for me: I would like to avoid the redundancy. As >> soon as I want to query for >> "Show all items which the current user is allowed to modify" I need the >> permission checking in a SQL WHERE condition. >> >> If I implement this. Then my code which might look like this is redundant: >> >> {{{ >> >> def has_perm(obj, user): >> if user.is_superuser: >> return True >> ... >> >> }}} >> >> >> Yes, I feel farewell pain. I love Python, but I guess I will use perm >> checking via SQL WHERE for new projects in the future. >> >> What do you think? >> Regards, >> Thomas Güttler >> >> [1]: >> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de >> >> -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-users/45859506-8dc4-09b9-8386-5a995917a247% > 40djangodeployment.com > <https://groups.google.com/d/msgid/django-users/45859506-8dc4-09b9-8386-5a995917a247%40djangodeployment.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALn3ei2EaxBWLX8YgqTkRHbHmP_rM_QjD%3DB%2B%2BMJPOR%2BuqsJQ_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
