Re: Making the admin compatible with CSP
On Monday, September 14, 2015 at 1:17:37 AM UTC+2, jasbligh wrote: > > I'd propose solving as follows > 1) use the autofocus attribute when creating the form. This will work for > IE10+ http://caniuse.com/#feat=autofocus It can also be done by including > a creating a few targeted one line js files and including instead of the > inline. It just seems a lot of http overhead to save users of two old > browsers having to click into a text input. > Why would we need one-line js files? If we decide against the autofocus attribute (this might get a little bit hard with the forms framework), we can still put a data-autofocus="#someif" into the body element and then add a handler for that. > 2) use
Re: Making the admin compatible with CSP
On 14 September 2015 at 11:52, Florian Apolloner wrote: > > > On Monday, September 14, 2015 at 1:17:37 AM UTC+2, jasbligh wrote: >> >> I'd propose solving as follows >> 1) use the autofocus attribute when creating the form. This will work for >> IE10+ http://caniuse.com/#feat=autofocus It can also be done by >> including a creating a few targeted one line js files and including instead >> of the inline. It just seems a lot of http overhead to save users of two >> old browsers having to click into a text input. >> > > Why would we need one-line js files? If we decide against the autofocus > attribute (this might get a little bit hard with the forms framework), we > can still put a data-autofocus="#someif" into the body element and then add > a handler for that. > Perfect, would you know where would be best to place the js in that case? (I've got the attribute working with the forms framework though) > >> 2) use
Re: Making the admin compatible with CSP
On Monday, September 14, 2015 at 1:54:06 PM UTC+2, jasbligh wrote: > > Perfect, would you know where would be best to place the js in that case? > (I've got the attribute working with the forms framework though) > Dunno, any existing file which has a few functions should do ;) If the form attribute code is nice, then by all means we should use that… > I'll put the json in views or a filter. There was a very relevant > discussion on this before with a gist by David Evans > https://groups.google.com/forum/#!msg/django-developers/RNMs5YbKeRY/ZtewE89xu_4J > Yes, that library marks the output as safe, which is quote dangerous is not used properly. > If it was my project I wouldn't have a target, that's my preferred style. > But felt if the code already have javascript:void(0) someone felt the need > for a href attribute and as my first contribution I didn't want to be > changing too much. > Ok, removing it should be fine then -- that is unless someone with more frontend experience speaks up :D 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/48fd14c2-d217-4623-8305-62ad165f0b18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: request for API review of streaming responses additions
On Monday, 7 September 2015 15:05:35 UTC+1, Aymeric Augustin wrote: > 2015-09-07 10:00 GMT+02:00 Yann Fouillat > > : > >> First I will say that most of this pull request is a port of >> https://github.com/django/django/pull/1037 which I ported more or less >> blindly. >> > > As far as I can tell, this previous PR was never discussed on > django-developers. Someone threw the code on GitHub, that's all; you can't > make any assumptions about its suitability for inclusion in Django. > The original ticket is at https://code.djangoproject.com/ticket/13910 where it was Accepted 5 years ago, that original PR done two years ago, and then rebased/worked on more this summer. That ticket also suggested the creation of "StreamingTemplateResponse" ;-) There was a brief discussion at https://groups.google.com/forum/#!searchin/django-developers/13910/django-developers/bpu5EHjnjDs/locX-gWm8PoJ and brief side mention at https://groups.google.com/forum/#!searchin/django-developers/13910/django-developers/OubwBVo_gxw/Avh1pdbpPMYJ – certainly nothing major, no. I think stream=False sounds like a good idea, I definitely wouldn't want to duplicate all the Mixin/Views for streaming/non-streaming. >From a performance point of view, I wrote a blog post about how not using streaming templates caused our entire server to fall over and what I wrote to work around the lack of streaming templates: https://www.mysociety.org/2015/06/01/django-streaminghttpresponse-json-html/ – it's certainly not a magic bullet but in certain circumstances would be very useful :-) ATB, Matthew I'm aware of the irony of me making this argument. I set a bad precedent > when I added StreamingHttpResponse. I didn't think of > HttpResponse(stream=True) at the time. The prospect of having 25 > StreamingFooBar classes in Django makes me realize this wasn't a great > idea. Let's learn from this mistake. (The stakes are a bit low to consider > fixing it through a deprecation path, though.) > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/da7ea431-0f47-45c1-a852-96650703fc29%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Making the admin compatible with CSP
> On 14 Sep 2015, at 11:52, Florian Apolloner wrote:
>
> Makes sense, depending on the actual parameters data attributes could make
> sense too for a few things. Oh, btw please do not handwrite JSON in
> templates, either do it in the view or use a filter to actually create JSON
> which then only needs to go through the autoescape filter I think (In that
> sense there is also not really a need for escapejs as far as I see it, but I
> might be wrong).
So I’ve had a go at this and I’ve come up against the how do you safely output
the json to the template without calling mark_safe problem. Having looked
around my solution is to output the json string with {{ json_string|escapejs
}}.
Then in the javascript call JSON.parse twice
JSON.parse(JSON.parse('"' + jsonString + '"'));
First parse wraps the json in quotes and returns the original unescaped string
which we can then turn into our data.
Because escapejs turns things into HEX codes which JSON.parse can easily
understand it is easy to decode but nice and safe to include in html. No chance
of closing script tags in the html output.
I’ve all of Florian’s other suggestions addressed, so next stage for me is to
create a pull request so someone can look at actual code and give feedback.
Give me another evening to figure that out.
James
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8D1D86A4-6404-449C-8353-F053EBB43A6E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
