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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> 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
> <https://groups.google.com/d/msgid/django-users/7d1eaa8c-d80a-4390-aaf9-8a95d3fcf6b4%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 [email protected].
To post to this group, send email to [email protected].
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.
