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).
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.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.
Regards,
Antonis
Antonis Christofides http://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-71e 8-01718444f338%40thomas-guettl er.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+unsubscribe@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
For more options, visit https://groups.google.com/d/optout .
To view this discussion on the web visit https://groups.google.com/d/--
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+unsubscribe@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 .msgid/django-users/45859506- .8dc4-09b9-8386-5a995917a247% 40djangodeployment.com
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+unsubscribe@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.
No comments:
Post a Comment