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.

Reply via email to