This is a problem with _any_ ASGI app, not just middleware - doing blocking things in the __init__ is bad.
I will look at the docs when I look at solving the SessionMiddleware problem as well, as the two are linked.
Andrew
On Sun, Mar 4, 2018 at 7:10 AM, Hugo Castilho <hcastilho@gmail.com> wrote:
--
The example in the Channels documentation shows it being used with a consumer called consumers.AsyncChatConsumer which suggests it's safe to use with async consumers.
There probably should be a note there that it's currently not safe to use with async consumers no?
Regarding the SessionMiddleware wouldn't this be part a more general problem with routers? As it is they currently have to be async "safe".
On Sunday, March 4, 2018 at 3:03:05 AM UTC, Andrew Godwin wrote:Hi Hugo,The AuthMiddleware, like its Django counterpart, does not query the auth backend immediately - it is lazily done the first time you access the scope["user"] object. This does present a risk that you could access it during an async method body, though - I will look into how we could fix this (it might mean making it non-lazy, but I don't quite know yet).The SessionMiddleware does have the problem you suggest, though - I have opened this issue to track it: https://github.com/django/channels/issues/949 AndrewOn Sat, Mar 3, 2018 at 5:49 PM, Hugo Castilho <hcas...@gmail.com> wrote:--
Hi all,
The channels authentication documentation (https://channels.readthedocs.io/en/latest/topics/authentica ) shows using the channels AuthMiddleware with an AsyncConsumer.tion.html
Now, my problem is that all session backends in Django are blocking.
I know that the user is only retrieved lazily but from what I understand this only means that instead of the blocking call happening during the instantiation of the application in daphne.Server.create_application it will happen in the AsyncConsumer.
Either way the call will be made in the event loop.
Are we not stopping the event loop for the first time every connection accesses request.user?
I'm sure I'm missing something here.
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/f9a7ec05-7d54 .-4459-a08a-20d6a931c8a3%40goog legroups.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+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/430b86ac- .d0d7-4d50-b32d-89f2bd117b0a% 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/CAFwN1urLP41zbpooSq7RWcXbK1qaiJXbOR_znuNfu9uzT7eBgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment