>
>
> Well, in that case I would consider defining the consumer as a required,
> but
> keyword (and keyword-only in Python3) argument, specified in the end by
> convention. Putting it between the channel and channel parameters is ugly
> IMO.
>
>
It would be easy enough to change all the docs and ex
On Saturday 02 April 2016 00:38:31 Andrew Godwin wrote:
> On Fri, Apr 1, 2016 at 11:32 PM, Shai Berger wrote:
> > Hi,
> >
> > Finally found the time to go through this discussion.
> >
> > The first note that comes to mind is:
> >
> > Although it has already been pointed out more than once that
On Fri, Apr 1, 2016 at 11:32 PM, Shai Berger wrote:
> Hi,
>
> Finally found the time to go through this discussion.
>
> The first note that comes to mind is:
>
> Although it has already been pointed out more than once that positional
> arguments cannot follow keyword arguments, you both (Andrew a
Hi,
Finally found the time to go through this discussion.
The first note that comes to mind is:
Although it has already been pointed out more than once that positional
arguments cannot follow keyword arguments, you both (Andrew and Vincent) keep
giving examples such as
# SYNTAX ERROR
On Tue, Mar 22, 2016 at 4:04 PM, Michael Manfre wrote:
>
> If not provided out of the box, there needs to be a supported way of
> wiring in encryption. The security/compliance person at my job stated that
> only securing the transport was not good enough for our compliance
> requirements when I w
On Tue, Mar 22, 2016 at 1:44 PM, Andrew Godwin wrote:
> Indeed, we run Redis over TLS tunnels at work to fulfill this requirement,
> so I know transport security is required, but at the same time reinventing
> it might be more work than we need - would you trust our internal symmetric
> encryptio
Indeed, we run Redis over TLS tunnels at work to fulfill this requirement,
so I know transport security is required, but at the same time reinventing
it might be more work than we need - would you trust our internal symmetric
encryption system, or go for TLS tunnels instead?
Still, if we want to d
> On Mar 22, 2016, at 1:24 PM, Jacob Kaplan-Moss wrote:
>
> I do think encrypting the Redis channel layer is something we should offer:
> Redis out of the box doesn't do transport-layer encryption, which is going to
> make Channels a hard sell to anyone with any for of regulatory/compliance
>
I do think encrypting the Redis channel layer is something we should offer:
Redis out of the box doesn't do transport-layer encryption, which is going
to make Channels a hard sell to anyone with any for of
regulatory/compliance requirements. [1]
I think probably Fernet [2] is the right way to do t
The channel layer could indeed use SECRET_KEY, since it's loaded in via a
Django codepath in both the protocol server and the worker server.
It's better done as a channel layer feature rather than in Channels/Daphne
directly, as then it requires no extra supporting code in anything else
that does
Assuming the frontend has access to DJANGO_SETTINGS_MODULE, couldn't it use
the SECRET_KEY to encrypt the message before passing it to the message
broker? On message receipt it could then use the SECRET_KEY to decrypt the
message. It'd be nice if encryption were an option encoded within the
mes
On Mon, Mar 21, 2016 at 12:11 PM, Sean Brant wrote:
> 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
On Mon, Mar 21, 2016 at 9:55 AM, David Evans 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 FileRespons
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
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.)
On Thu, Mar 17, 2016 at 1:44 PM, Florian Apolloner
wrote:
> Yes, this seems like a major pain point, especially since the routing does
> not scale if you add another app, ie you need to add a wrapper which then
> dispatches to the individual connect routines. In a best case scenario I'd
> just ha
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!
I
You're right. Assume I put the keyword arguments at the end, sorry - the
two positional arguments are the channel name and the consumer.
On Fri, Mar 18, 2016 at 12:21 PM, Ryan Hiebert wrote:
>
> On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote:
>
> routing = [
> route("http.request", ViewCo
I like most of it apart from the fact you can set a consumer to consume ANY
channel, which seems incredibly dangerous - when a channel is wrongly
consumed the only visible error is usually just a lack of response to the
end client, and no two channels have messages that are similar in any
useful wa
Yes, my intent is that "path" is just a stand-in for "any string key in a
message", thus you could route other ways (for example, `method` in
http.request, though that's probably not super useful inside Django).
Andrew
On Sat, Mar 19, 2016 at 1:40 PM, Vincent wrote:
> Andrew,
>
> Thanks for the
Andrew,
Ah, excellent. I just took a short break (too many LOC at work today), and
while I was away I was thinking about all of this.
Here's what I came up with:
https://gist.github.com/orokusaki/17b4cf734b4d2f2af117
On Friday, March 18, 2016 at 3:57:38 PM UTC-4, Andrew Godwin wrote:
>
>
>
> O
Andrew,
Thanks for the explanation.
(re: including based only on path, routing based on channel (and optionally
path?)), I really really like that simplicity, the more I think about it.
Expanding on that to include your prior examples, I'm assuming `path` is
just incidental for http / websocke
On Thursday, March 17, 2016 at 9:56:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> I'd considered an API like this, and it's certainly clean and
> straightforward. However, we've already got a URL routing library in
> Django, so I think I'd like to try to find a way to re-use it for
> websockets. I
On Thu, Mar 17, 2016 at 1:41 PM, Jacob Kaplan-Moss
wrote:
>
>
> 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 coul
Perhaps it is a bit early for this but Is there anywhere origin is checked
against ALLOWED_HOSTS ?
Middleware support would be nice to but I guess you'll come to that when
implementing user authentication.
Keep up the great work !
--
You received this message because you are subscribed to the G
Hi Vincent,
I think you make some good points - in particular, I think includes are
probably a necessity, as you say. However, I disagree we should let people
have either channel->url or url->channel; I'd like us not to try and give
people multiple ways to do things if we can help it, especially i
Also note, I just copy-pasted the same SyntaxError (kwarg before arg).
On Friday, March 18, 2016 at 3:40:22 PM UTC-4, Vincent wrote:
>
> Hey Andrew,
>
> Thanks for looking through all that, and for the reply.
>
> I like the simplicity of your updated examples. I started to make a
> counter-exampl
> On Mar 18, 2016, at 9:58 AM, Andrew Godwin wrote:
>
> routing = [
> route("http.request", ViewConsumer),
> route("websocket.connect", path="^chat/(?P[^/]+)/$", ChatConnect),
> route("sms.receive", sender="+44(?P[0-9]+)$",
> UkSmsConsumer),
> include(path="^notifications", "not
On Thursday, March 17, 2016 at 5:42:05 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> 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
Jacob, Florian, Andrew,
I've spent the last 200 minutes thinking this through and writing, and
here's what I've come up with:
https://gist.github.com/orokusaki/c67d46965a4ebeb3035a
Below are the full contents of that Gist (but I recommend the Gist for
formatting).
I also created https://githu
Hey Andrew,
Thanks for looking through all that, and for the reply.
I like the simplicity of your updated examples. I started to make a
counter-example to suggest that `include` be inside of a `route`
(https://gist.github.com/orokusaki/c0c934013ee7911071ef).
But then, as I thought through this
On Fri, Mar 18, 2016 at 4:40 PM, Vincent wrote:
> Hey Andrew,
>
> Thanks for looking through all that, and for the reply.
>
> I like the simplicity of your updated examples. I started to make a
> counter-example to suggest that `include` be inside of a `route` (
> https://gist.github.com/orokusak
32 matches
Mail list logo
