How does the new channels model handle requests with sensitive information? Say you have a login view and the user is submitting a username/password. Does the password get serialized into the message queue as plain text? If so is that a security concern users should be aware of?
Sean On Mon, Mar 21, 2016 at 7:55 AM, David Evans <drh.ev...@gmail.com> wrote: > On the static files question, I'm about to release v3 of WhiteNoise ( > http://whitenoise.evans.io/en/latest/changelog.html) which provides the > option to integrate via Django middlware, rather than wsgi middleware. (It > uses the FileResponse class, which didn't exist when I first wrote > WhiteNoise.) I'm hoping (though I haven't tested it yet) that this will > work out of the box with Channels, as it's only using standard Django APIs. > > Dave > > > On Thursday, 17 March 2016 16:42:05 UTC, Jacob Kaplan-Moss wrote: >> >> Hi folks (and especially Andrew): >> >> I've just completed writing an example Channels app [1] for an article >> about Channels [2]. Overall it was a super-pleasant experience: Channels >> seems pretty solid, the APIs make sense to me, and I couldn't be more >> excited about the new things this'll let me do! >> >> In the interests of making this thing as solid as possible before we >> merge it into Django, I do have some feedback on some of the hiccups I >> encountered. Roughly in order of severity (as I perceive it), they are: >> >> 1. Debugging errors: >> >> I found debugging errors that happen in a consumer to be *really* >> difficult -- errors mostly presented as things just silently not working. >> It took a ton of messing around with logging setups before I could get >> anything of use dumped to the console. This isn't strictly a Channels issue >> (I've noted similar problems with AJAX views and errors in Celery tasks), >> but I think Channels sorta brings the issue to a head. >> >> I think we need some better defaults, and simple, clear documentation, to >> make sure that exceptions go somewhere useful. >> >> 2. Static files: >> >> I had trouble getting static files served. I'm used to using Whitenoise ( >> http://whitenoise.evans.io/en/stable/) for small-to-medium-ish sites >> that don't need a proper static server, but of course it doesn't work with >> Channels since Channels doesn't use WSGI! I found the (undocumented) >> StaticFilesConsumer ( >> https://github.com/jacobian/channels-example/blob/master/chat/routing.py#L5-L8), >> but that feels less than ideal. >> >> I think this might be an opportunity, however. If Daphne learns how to >> serve static files (perhaps via optional integration with Whitenoise?), >> this would actually make static media in Django a bit easier by default. >> >> [I would be happy to work on this if I get a thumbsup.] >> >> 3. WebSocket routing: >> >> Channels routes all WebSocket connections to a single set of consumers >> (the `websocket.*` consumers). This means that if you want multiple >> WebSocket URLs in a single app you need to manually parse the path. And, to >> make things more complicated, you only get the WebSocket path passed in the >> connection message, so you have to also use a channel session to keep track. >> >> This feels like a distinct step back from the URL routing we already have >> in Django, and it was surprising to me to have to do this by hand. It >> definitely felt like Channels is missing some sort of WebSocket URL router. >> >> I had a brief chat with Andrew, who indicates that he'd planned for this >> to be a post-1.0 feature. I'm not sure I agree - it feels pretty >> fundamental - but I'd like to hear other thoughts. >> >> [This is another thing I'd be interested in working on, assuming a >> thumbs.] >> >> --- >> >> Has anyone else here played with Channels? Are there other things I'm >> missing that might need to be included before we merge this? >> >> Jacob >> >> [1] https://github.com/jacobian/channels-example >> >> [2] >> https://blog.heroku.com/archives/2016/3/17/in_deep_with_django_channels_the_future_of_real_time_apps_in_django >> ? >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/ba29cc7a-90fc-4cf2-a65d-da782e83b3ca%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/ba29cc7a-90fc-4cf2-a65d-da782e83b3ca%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 developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPNuhQyitDrB07B-m0sPWhLbT%3Dm_K7CWTddyKobCVqmiA2uFTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
