Just like the one they posted, but with a few minor changes: async def __call__(self, scope, receive, send): and: return await self.inner( dict(scope, schema_name=schema_name, multitenant=True), receive, send )
Also, check if AuthMiddleware is using the channels.auth.get_user() function within the correct schema. David Emanuel Sandoval <https://www.linkedin.com/in/david-emanuel-sandoval/> WEB DEVELOPER +549 3734 607102 <https://linkedin.com/in/david-emanuel-sandoval/> <https://github.com/emasmach/> El sáb, 27 ene 2024 a las 14:14, David Emanuel Sandoval (< [email protected]>) escribió: > To identify the tenant i used a middleware that extract the tenant from > the domain. > > El sáb, 27 ene 2024, 10:28, Nagaraja <[email protected]> escribió: > >> Y cnt u use pusher instead of channels >> >> On Sat, 27 Jan, 2024, 4:40 pm 'Sebastián García' via Django users, < >> [email protected]> wrote: >> >>> Hi, I'm reviving this old thread... do you know of any other solution to >>> the one proposed by @Ahmed Ishtiaque >>> >>> Thanks >>> El domingo, 24 de febrero de 2019 a la(s) 9:13:30 p.m. UTC-3, Ahmed >>> Ishtiaque escribió: >>> >>>> @N Muchai, >>>> >>>> I don't know if you've found a workaround to this, but here's mine if >>>> people are interested in the future. >>>> >>>> I just made a custom ASGI application that adds the tenant schema name >>>> (provided your URLs are in the form *.domain.com, where * represents >>>> the schema name) and whether the project is multitenant or not. I haven't >>>> thought much about whether the boolean for multitenancy identifier helps, >>>> so feel free to remove it in your implementation. I just stacked this >>>> application in my project's `routing.py` file. Here's the code I have at >>>> the moment: >>>> >>>> My Middleware: >>>> class MTSchemaMiddleware: >>>> def __init__(self, inner): >>>> self.inner = inner >>>> >>>> def __call__(self, scope): >>>> if "headers" not in scope: >>>> raise ValueError( >>>> "MTSchemaMiddleware was passed a scope that did not >>>> have a headers key " >>>> + "(make sure it is only passed HTTP or WebSocket >>>> connections)" >>>> ) >>>> >>>> for key, value in scope.get('headers', []): >>>> if key == b'host': >>>> schema_name = value.decode('ascii').split('.')[0] >>>> break >>>> else: >>>> raise ValueError( >>>> "The headers key in the scope is invalid. " >>>> + "(make sure it is passed valid HTTP or WebSocket >>>> connections)" >>>> ) >>>> return self.inner( >>>> dict(scope, schema_name=schema_name, multitenant=True) >>>> ) >>>> >>>> My `routing.py`: >>>> >>>> import MTSchemaMiddleware # from wherever your Middleware class resides >>>> application = ProtocolTypeRouter({ >>>> 'websocket': <your stack>( >>>> MTSchemaMiddleware( >>>> URLRouter( >>>> chat.routing.websocket_urlpatterns >>>> ) >>>> ) >>>> ) >>>> }) >>>> >>>> After you do this, you will be able to access the `schema_name` and >>>> `multitenant` variables inside your consumer's `scope` like this: >>>> `schema_name = scope['schema_name']` or `multitenant = >>>> scope[`multitenant`]`. >>>> >>>> Hope this helps someone! >>>> >>>> Best, >>>> Ahmed >>>> >>>> >>>> >>>> On Thursday, January 10, 2019 at 7:22:40 AM UTC-5, N Muchai wrote: >>>>> >>>>> @Filbert, >>>>> >>>>> Am in the same exact spot using Django Channels with django-tenants. Did >>>>> you find a way to identify the tenant? >>>>> >>>>> Thanks. >>>>> >>>>> On Tuesday, November 28, 2017 at 4:22:10 AM UTC+3, Filbert wrote: >>>>>> >>>>>> Sorry, yeah dig before I post :-| Can create a class-based consumer >>>>>> and use the message->headers->host. I'll get chest deep before ask >>>>>> another >>>>>> question. >>>>>> >>>>>> On Monday, November 27, 2017 at 6:04:48 PM UTC-5, Andrew Godwin wrote: >>>>>>> >>>>>>> That would be correct (though please be aware Origin can be faked >>>>>>> like host headers, so don't use it as the sole point of security). >>>>>>> >>>>>>> Is it not available via the headers list in the connect message? >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> On Mon, Nov 27, 2017 at 2:58 PM, Filbert <[email protected]> wrote: >>>>>>> >>>>>>>> Thanks again. One last question, in order to "multi-tenant-ify" >>>>>>>> Channels I think the challenge will be trickle the websocket "orgin" >>>>>>>> into >>>>>>>> the consumer from Daphne somehow as it seems there is no way to know >>>>>>>> in a >>>>>>>> consumer which tenant (unique domain) the message originated from. >>>>>>>> Without >>>>>>>> the domain you can't establish the Postgres schema, without the schema >>>>>>>> you >>>>>>>> have no tenant :-) >>>>>>>> >>>>>>>> Please confirm this would be the approach or whether I am >>>>>>>> wrong-headed here. >>>>>>>> Thanks. >>>>>>>> >>>>>>>> On Sunday, November 26, 2017 at 9:58:58 AM UTC-5, Andrew Godwin >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I've never used attach-daemon so I can't help you there I'm >>>>>>>>> afraid. As long as it does sensible process-management things it's >>>>>>>>> probably >>>>>>>>> alright? >>>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> On Sat, Nov 25, 2017 at 5:17 PM, Filbert <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Andrew, >>>>>>>>>> Thanks for the response. Seeing that I am keeping uWSGI for the >>>>>>>>>> non-websocket paths, any heartache with me starting daphne and the >>>>>>>>>> consumers using uWSGI's attach-daemon? I do this with celery and it >>>>>>>>>> is a >>>>>>>>>> convenient way to have everything for the App managed as a unit via a >>>>>>>>>> single /etc/init (upstart) conf file. >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On Friday, November 24, 2017 at 7:10:29 PM UTC-5, Andrew Godwin >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Your assumptions all seem correct. Also consider that the >>>>>>>>>>> security model of WebSockets is... interesting, so securing a >>>>>>>>>>> multi-tenant >>>>>>>>>>> setup is going to require a bit more work than you would merely >>>>>>>>>>> doing the >>>>>>>>>>> same for HTTP requests. >>>>>>>>>>> >>>>>>>>>>> There are other non-Channels options around if you want to look >>>>>>>>>>> into them, but I suspect they'll all have similar architectural >>>>>>>>>>> challenges. >>>>>>>>>>> >>>>>>>>>>> Andrew >>>>>>>>>>> >>>>>>>>>>> On Fri, Nov 24, 2017 at 3:09 PM, Filbert <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Running multi-tenant site using a fork of Django tenant schemas >>>>>>>>>>>> with tens of web servers and thousands of tenants.... >>>>>>>>>>>> >>>>>>>>>>>> Piloting a project to implement Channels for real-time >>>>>>>>>>>> notifications, etc. >>>>>>>>>>>> >>>>>>>>>>>> I want to confirm these assumptions: >>>>>>>>>>>> >>>>>>>>>>>> 1. Channels really has no support for multi-tenant, I will have >>>>>>>>>>>> to roll my own. >>>>>>>>>>>> 2. Since uWSGI is serving us well and (at this point) I >>>>>>>>>>>> wouldn't trust Daphne to serve HTTP, I've got split paths in NGinx >>>>>>>>>>>> for >>>>>>>>>>>> uWSGI and ASGI. >>>>>>>>>>>> 3. We are running RabbitMQ, so we have to cluster it and >>>>>>>>>>>> implement channels using asgi_rabbitmq (Redis would just add yet >>>>>>>>>>>> another >>>>>>>>>>>> moving part) >>>>>>>>>>>> 4. Plan on significant additional resource requirements on the >>>>>>>>>>>> web server and serious scaling challenges. >>>>>>>>>>>> >>>>>>>>>>>> Are their any other non-Channels options, or is it the really >>>>>>>>>>>> the only game in town? >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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/aae2725b-d873-40fd-ae09-d1668ab9e727%40googlegroups.com >>>>>>>>>>>> <https://groups.google.com/d/msgid/django-users/aae2725b-d873-40fd-ae09-d1668ab9e727%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/d4906dc8-040b-4ee0-b11d-a7cc918b9e5d%40googlegroups.com >>>>>>>>>> <https://groups.google.com/d/msgid/django-users/d4906dc8-040b-4ee0-b11d-a7cc918b9e5d%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/4d7c94f1-81ad-4949-a987-35f45b188c2f%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/django-users/4d7c94f1-81ad-4949-a987-35f45b188c2f%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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/daa6bec0-905d-415e-a63f-7d9b6efd8fa4n%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-users/daa6bec0-905d-415e-a63f-7d9b6efd8fa4n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CAN1LePgGs%2BqAucxJvtpY6M%2BAZoWu6rzk9SSHYrdW_sWSJZWAsg%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAN1LePgGs%2BqAucxJvtpY6M%2BAZoWu6rzk9SSHYrdW_sWSJZWAsg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHUWMCa8wttAfs0XrSvGDX-jYuuDE4u3_Hht5Bkw6ALj5Gx-RQ%40mail.gmail.com.
