Channels + django-tenants

[l***@gmail.com]

Django-tenants is a package to provide multi-tenancy in Django through
Postgres schemas (https://github.com/tomturner/django-tenants/)

Django-tenants relies on setting the schema on the connection in order to
make queries to the right Postgres schema. When you want to secure your
consumers with user permissions, django-tenants needs to be properly routed
in order to retrieve the right users from database, otherwise the user in
scope is not properly populated for permission checking.

In order to overcome this, I have redefined (in a not DRY way, aka
copy/paste) `get_user`, `TenantAuthMiddleware` and
`TenantAuthMiddlewareStack`, just because I basically need to wrap
`get_user` inside `with scope["tenant"]` (provided I put the tenant in the
scope before, in a custom router.)

Is there any way to provide a hook so this can be achieved in a DRY way?

[Andrew Godwin]

What sort of hook would you be imagining? The DB connection stuff is deep
inside Django itself, rather than in Channels, so I'm not sure what
sensible top-level thing we could provide that would make sense.

Andrew

Post by l***@gmail.com
Django-tenants is a package to provide multi-tenancy in Django through
Postgres schemas (https://github.com/tomturner/django-tenants/)
Django-tenants relies on setting the schema on the connection in order to
make queries to the right Postgres schema. When you want to secure your
consumers with user permissions, django-tenants needs to be properly routed
in order to retrieve the right users from database, otherwise the user in
scope is not properly populated for permission checking.
In order to overcome this, I have redefined (in a not DRY way, aka
copy/paste) `get_user`, `TenantAuthMiddleware` and
`TenantAuthMiddlewareStack`, just because I basically need to wrap
`get_user` inside `with scope["tenant"]` (provided I put the tenant in the
scope before, in a custom router.)
Is there any way to provide a hook so this can be achieved in a DRY way?
--
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
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/c547563c-a8a6-416c-bf59-54907f512c77%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/c547563c-a8a6-416c-bf59-54907f512c77%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[l***@gmail.com]

I know this is not general, but maybe `get_user` could accept an optional
function as second parameter, so that the function could wrap the inner
content of the current `get_user`. django-tenants provides a regular
middleware, but I think the async breaks any attempt to handle this through
a channels-like middleware.

[Andrew Godwin]

Hm, that's not sufficiently better than just supplying a new middleware to
be honest. The sort of hooks I prefer are where you can subclass and
improve what we ship with and give the user a new, non-fragile one, whereas
that just sounds like it's injecting a function in.

Honestly, given Channels is currently only one maintainer, any increase in
surface area is unlikely unless there's a very good reason. Channels' auth
stuff is just standard Django code + settings for the most part, so there's
already bits you can reuse to do most of the work.

Andrew

Post by l***@gmail.com
I know this is not general, but maybe `get_user` could accept an optional
function as second parameter, so that the function could wrap the inner
content of the current `get_user`. django-tenants provides a regular
middleware, but I think the async breaks any attempt to handle this through
a channels-like middleware.
--
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
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/f99a231f-cdc5-426f-8d0a-20c0f8ebc2fc%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/f99a231f-cdc5-426f-8d0a-20c0f8ebc2fc%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.