Re: django.core.signing and safe characters
Hi again!
I'm sorry if I gave the impression that I'm trying to nitpick
adherence to a standard. There was some discussion about it in the
comments in the link I provided, and it looks like there are different
interpretations, but that's not what I'm interested in.
What I'm addressing here is specifically the comment in the source and
the assumptions it is making, which I have found confusing in practice
because I bumped into the encoding issues.
Reading that comment, I expect to be able get a token and construct a
URL with it, and get a nice URL with no percent goo in it. I don't
expect URL safe strings to be encoded by standard API, neither in the
browser or server-side.
>> It is used for the scheme "https:". encodeURIComponent(":") returns "%3A".
>
> The usefulness of that function seems questionable to me.
Could you elaborate why? What other function would you use client-side
to make sure that you generate a valid query string given a set of
parameters?
Python does the same, by the way:
$ python3
>>> import urllib.parse
>>> urllib.parse.quote(":")
'%3A'
>>> urllib.parse.urlencode({ ':foo': ':bar' })
'%3Afoo=%3Abar'
It looks like urllib is more eager when it comes to escaping, * is
also escaped by default. . isn't. So it would probably have been
better if the signing code had picked . as default separator.
Ole
--
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/CANb2Ov%2BNaz_cpH%2BTRYQ5FvGeCM33r6nFm%3D7sv55g6wfO6PhnGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: On ASGI...
> My ideal solution is one that allows both approaches, and I'd like to
investigate that further. I think you're getting closer to the sort of
thing I'm imagining with the uvcorn designs, but I feel like there's still
something a little extra that could be done so it's possible to offload
over a network easily (as you mention, letting consumers go to channel
layers).
Indeed. Centering on the consumer interface doesn't mean that using a
channel layer isn't an option, just that it's not the base case. It also
composes really nicely, in the same way as WSGI middleware eg...
app = router({
'http.request': wsgi_adapter(wsgi_app),
'websocket.*': redis_channel_layer(...)
})
> If we end up with one format for channel names and messages that is
spread across two consumption forms (in-process async and cross-process
channel layers), I think that would still be a useful enough standard and
make a lot more people happy.
Yes. I'm not sure if there aren't also reasonable ways to have standard
non-asyncio frameworks deployed directly behind a server, too. Personally
I'm looking at using your work to fill the gap of having no WSGI equivalent
in the asyncio framework space.
> I wish there was a nicer way to achieve this than having send_async() and
send_group_async() methods (etc.), but the only other alternative I see is
having the methods all mirrored on an .async object, as in
"channel_layer.async.send()". I'm not sure how I feel about that - thoughts?
First thought is that the same issue likely applies to a bunch of the
extension methods. That's a good argument in favour of keeping the API
surface area as minimal as possible. I'm still keen on an API that only
exposes data and channel send/receive primitives (and associated error
handling), and simply doesn't allow for anything beyond that.
The naming aspect has plenty of bikeshedding potential. My current
preference probably sounds a little counter-intuitive, in that I'd be happy
to see synchronous and asyncio version of the interface be two incompatible
takes on the same underlying interface. ie. name them send() and receive()
in *both* cases. You don't ever want to expose the sync version to an
asyncio framework, or vice versa.
Asyncio essentially introduces a language within a language, eg. it
wouldn't be unreasonable to see an `apython` interpreter in the future,
that fully replaced all the incompatible parts of the standard library with
coroutine equivalents, so I wouldn't have a problem with treating it almost
as two separate language implementations against the same spec. I don't
think it's worth getting hung up on resolving this aspect just yet tho.
Less contentious would be at least asking the question "should we treat the
interface as asyncio-first (eg. send/send_blocking) or sync-first
(send/send_async)?"
Cheers,
Tom
--
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/0ffcaeca-9066-4351-aebb-11d826e6a215%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: django.core.signing and safe characters
Hi Ole,
On Wednesday, June 21, 2017 at 12:42:39 PM UTC+2, Ole Laursen wrote:
>
> I'm sorry if I gave the impression that I'm trying to nitpick
> adherence to a standard.
>
You absolutely did not, I guess my mail was tenser than it was intended to
be.
> What I'm addressing here is specifically the comment in the source and
> the assumptions it is making, which I have found confusing in practice
> because I bumped into the encoding issues.
>
There is certainly no problem with adjusting the comment to be more
accurate.
>> It is used for the scheme "https:". encodeURIComponent(":") returns
> "%3A".
> >
> > The usefulness of that function seems questionable to me.
>
> Could you elaborate why? What other function would you use client-side
> to make sure that you generate a valid query string given a set of
> parameters?
>
Sorry I've mixed it up with with encodeURI. encodeURIComponent takes the
"safe" route and escapes everything (at least as far as I understand it)
because it does not know where the component (unless "component" itself has
a sepcific meaning that I am not aware of) ends up -- this also makes the
function somewhat ugly to use because you escape more than you need to. On
the other hand, if you use encodeURI:
encodeURI('http://google.com?:a=:asd')
"http://google.com?:a=:asd";
it does not escape ':' since it knows that there is no need to escape it.
It looks like urllib is more eager when it comes to escaping, * is
> also escaped by default. . isn't. So it would probably have been
> better if the signing code had picked . as default separator.
>
I think this is a result of internally going through quote which only
allows safe characters which are safe in every context. Whether that is a
good decision or not, I do not know. It would probably have been better to
choose '.' as delimiter, but I am not sure that the effort to change that
is worth it. In the end I fear that a stylistic change is just not worth it
(that doesn't mean that the documentation shouldn't be accurate though).
Cheers,
Florian
--
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/a2c27242-d443-4493-80ab-7f702e9fc911%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: django.core.signing and safe characters
2017-06-21 15:26 GMT+02:00 Florian Apolloner :
> Sorry I've mixed it up with with encodeURI. encodeURIComponent takes the
> "safe" route and escapes everything (at least as far as I understand it)
> because it does not know where the component (unless "component" itself has
> a sepcific meaning that I am not aware of) ends up -- this also makes the
> function somewhat ugly to use because you escape more than you need to. On
> the other hand, if you use encodeURI:
>
> encodeURI('http://google.com?:a=:asd')
> "http://google.com?:a=:asd";
>
> it does not escape ':' since it knows that there is no need to escape it.
This is a side note, but actually encodeURI can't be used to encode
query string parameters. It won't quote = or & either, as you can see
from your example. You need to use encodeURIComponent on each of the
parts separately.
So of the pair, encodeURI is probably the one that has questionable
use as you said, I've personally never needed it.
Ole
--
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/CANb2OvK9AfqBJCa35qOnkELtdTpp7SuMtqqsqJ5kYdHNha4d6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Vendoring Select2
Hi there,I worked on a fix for form media today. No it will keep the order and we can include our own scripts before calling noConflict.This way we don't have to wrapp all vendored JS libraries.Furthermore it makes the order of your assets more reliable than before and throws a warning if there are conflicts.https://github.com/django/django/pull/8667Enjoy :)-Joe--Johannes HoppeFon: +49 1511 4455 910www.johanneshoppe.comLennéstr. 1914469 PotsdamUSt-IdNr.: DE284754038 On Jun 18 2017, at 10:48 pm, Jamesie Pic wrote: Awesome, hope this will help drag in maintainer activity on select2 <3 Best -- You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/tCNWnLP8jzM/unsubscribe. To unsubscribe from this group and all its topics, 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/CAC6Op1_P-cvdqT_XeTGPrsuRSXN%3DRS3aF_MokofVVS_eF12_JA%40mail.gmail.com. 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/local-cfaf00d3-7c9b%40nylas-mail.nylas.com. For more options, visit https://groups.google.com/d/optout.
