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/CAHUWMCZ2r%2BBO5g7hws_uH7-M5VchZ3taA67Z11SnG5zz4436dw%40mail.gmail.com.
