Re: Django Channels and multi-tenant will this be a world of hurt?

[Andrew Godwin]

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  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 django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> 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
> 
> .
> 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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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/CAFwN1urh-Mb%3D2ZRtwyvZPh9CQoUDHrqN30yQUxhUd5GbUT8XfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and multi-tenant will this be a world of hurt?

[Etienne Robillard]

Hi,

What is a multi-tenant site?

how can i build a multi-tenant django app for django-hotsauce and 
asyncio without django-channels?


Thank you,

Etienne

Le 2017-11-24 à 19:09, Andrew Godwin a écrit :
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 > 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 django-users+unsubscr...@googlegroups.com
.
To post to this group, send email to django-users@googlegroups.com
.
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

.
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 django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

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/CAFwN1urh-Mb%3D2ZRtwyvZPh9CQoUDHrqN30yQUxhUd5GbUT8XfA%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

--
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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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/0e0de25c-c9b3-ffea-8d48-63aba327c35e%40yandex.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and multi-tenant will this be a world of hurt?

[Filbert]

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 > 
> 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 django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> 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
>>  
>> 
>> .
>> 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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and multi-tenant will this be a world of hurt?

[Andrew Godwin]

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  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  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 django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-users/aae2725b-d873-40fd-ae09-d1668ab9e727%40googlegroups.com
>>> 
>>> .
>>> 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 django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> 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
> 
> .
>
> 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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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/CAFwN1uoL7364SQzyXA-bRJ%3DXOja7FBXTcOTtCP5h7e3ZrAmvFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and multi-tenant will this be a world of hurt?

[Filbert]

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 > 
> 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  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 django-users...@googlegroups.com.
 To post to this group, send email to django...@googlegroups.com.
 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
  
 
 .
 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 django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> 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
>>  
>> 
>> .
>>
>> 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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and multi-tenant will this be a world of hurt?

[Andrew Godwin]

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  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  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  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 django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> 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
> 
> .
> 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 django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-users/d4906dc8-040b-4ee0-b11d-a7cc918b9e5d%40googlegroups.com
>>> 
>>> .
>>>
>>> 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 django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> 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
> 

Re: Django Channels and multi-tenant will this be a world of hurt?

[Filbert]

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 > 
> 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  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  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 django-users...@googlegroups.com.
>> To post to this group, send email to django...@googlegroups.com.
>> 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
>>  
>> 
>> .
>> 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 django-users...@googlegroups.com.
 To post to this group, send email to django...@googlegroups.com.
 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
  
 
 .

 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 a

Re: Django Channels and multi-tenant will this be a world of hurt?

[N Muchai]

@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  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  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  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 django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> 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
>>>  
>>> 
>>> .
>>> 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 django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> 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
>  
> 

Re: Django Channels and multi-tenant will this be a world of hurt?

[Lorenzo Peña]

>
>
>
Hi Filbert, everyone!

django-tenant-schemas has a way to infer the tenant from the request, and 
you could apply the same logic to extend Channel's scope with the tenant. 
With the tenant on the scope you can incrementally add in-channels 
multi-tenant logic. Not sure if this helps as you mention other multiple 
elements in your setup.
 

 

-- 
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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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/f1091e87-96b6-469a-9a92-46a82f0107f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and multi-tenant will this be a world of hurt?

[Ahmed Ishtiaque]

@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': (
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  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  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  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 ha

Re: Django Channels and multi-tenant will this be a world of hurt?

['Sebastián García' via Django users]

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': (
> 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  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  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

Re: Django Channels and multi-tenant will this be a world of hurt?

[Nagaraja]

Y cnt u use pusher instead of channels

On Sat, 27 Jan, 2024, 4:40 pm 'Sebastián García' via Django users, <
django-users@googlegroups.com> 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': (
>> 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  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  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

Re: Django Channels and multi-tenant will this be a world of hurt?

[David Emanuel Sandoval]

To identify the tenant i used a middleware that extract the tenant from the
domain.

El sáb, 27 ene 2024, 10:28, Nagaraja  escribió:

> Y cnt u use pusher instead of channels
>
> On Sat, 27 Jan, 2024, 4:40 pm 'Sebastián García' via Django users, <
> django-users@googlegroups.com> 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': (
>>> 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  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  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

Re: Django Channels and multi-tenant will this be a world of hurt?

[David Emanuel Sandoval]

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 
WEB DEVELOPER
+549 3734 607102








El sáb, 27 ene 2024 a las 14:14, David Emanuel Sandoval (<
davidemanuelsando...@gmail.com>) 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  escribió:
>
>> Y cnt u use pusher instead of channels
>>
>> On Sat, 27 Jan, 2024, 4:40 pm 'Sebastián García' via Django users, <
>> django-users@googlegroups.com> 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': (
 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  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
>>>