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:
-- 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?AndrewOn Mon, Nov 27, 2017 at 2:58 PM, Filbert <tim...@gmail.com> 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?AndrewOn Sat, Nov 25, 2017 at 5:17 PM, Filbert <tim...@gmail.com> wrote:To view this discussion on the web visit https://groups.google.com/d/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.AndrewOn Fri, Nov 24, 2017 at 3:09 PM, Filbert <tim...@gmail.com> 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 .msgid/django-users/d4906dc8- .040b-4ee0-b11d-a7cc918b9e5d% 40googlegroups.com
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/4d7c94f1- .81ad-4949-a987-35f45b188c2f% 40googlegroups.com
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+unsubscribe@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/b80cf4e9-df1f-4c33-8aa1-96eec913fd13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment