Sharing a single DB user for all/multiple Web app users allows
connection pooling. Otherwise, you have to create a new DB
connection for each HTTP request, or at least for each web app
user. Creating DB connections is relatively slow.
At least, I learned this reason 20 years ago, and assume it is
still true. On the other hand, I've never checked to see whether
Django uses a connection pool by default, and it seems pretty
quick.
Does Django use a connection pool?
Fred Stluka -- mailto:fred@bristle.com -- http://bristle.com/~fred/
Bristle Software, Inc -- http://bristle.com -- Glad to be of service!
Open Source: Without walls and fences, we need no Windows or Gates.
Hi,
This was discussed three months ago (the subject was "DATABASE DICTIONARY in Settings.py"), and this was my opinion:
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-07-11 12:40, guettli wrote:
I guess most applications have exactly one database user.--
Why not use one database for each application user?
Example: User "foo" in my web application has a corresponding database user "foo".
This way you could use row level security from the database.
PostgreSQL has a lot of interesting features: https://www.postgresql.org/docs/devel/static/ddl-rowsecurity.html
Use case: Show me all items which user "foo" is allowed to see.
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/7d1eaa8c-d80a-4390-aaf9-8a95d3fcf6b4%40googlegroups.com.
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+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/31981958-2d3e-6c02-eb57-0817676be6d0%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment