Thank you to our security aware developers
I want to give a big "thumbs up" to the folk that worked on InlineForeignKeyField, inlineformset_factory, and their friends. I just used inlineformset_factory for my project, saw that it was writing the parent id out into hidden form variables and, thinking that this seemed "unnecessary" and a possible vector for an attack. Ie, anything that's in the hands of the end-user should never be trusted. So, I faked up a page that had all the proper stuff, but changed one of the IDs in the hidden field to point to a different parent, and submitted. I got: "The inline foreign key did not match the parent instance primary key." Woot! Very good. Thank you, guys! The only nit I'd have about this is that (I think) this error message should never occur, and if it does, something is wrong that is outside the hands of a (normal) end-user. Something less "you did something (too complex to understand) wrong" would likely be better , such as: "Web-site internal error. Inline foreign key mismatch." To an end-user that seems like enough programmer-ese that they'll not try hunting to figure out what _they_ did wrong. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/qlav3hLbnOoJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: delegating our static file serving
Also consider the media files could number into the millions (or bajizillions?). Particularly for, say, a image hosting application. Clearly it would not be feasible to enumerate all the files, and there would clearly be regular additions. It might be that this use case is simply "beyond the scope" of a django-supplied static files server, and the developer should instead use nginx, lighttpd or something similar. On Tuesday, December 29, 2015 at 9:31:02 AM UTC-8, David Evans wrote: > > 2. Serving media files is a slightly different case. WhiteNoise was > designed around the assumption that it's serving a set of > developer-supplied, public files which remain unchanged during the lifetime > of the process. This simplifies a lot of performance and security concerns > that come with serving mutable, user-supplied files. At present, if you use > `add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)` as you > suggested then WhiteNoise won't pick up any files that were uploaded after > the application was started -- at least, not unless you enable the > "autorefresh" setting which I explicitly don't recommend for production. > -- 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/d489de11-018a-40e0-8419-40b4d18de9a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: delegating our static file serving
Also consider the media files could number into the millions (or bajizillions?). Particularly for, say, a image hosting application. Clearly it would not be feasible to enumerate all the files, and there would clearly be regular additions. It might be that this use case is simply "beyond the scope" of a django-supplied static files server, and the developer should instead use nginx, lighttpd or something similar. On Tuesday, December 29, 2015 at 9:31:02 AM UTC-8, David Evans wrote: > > 2. Serving media files is a slightly different case. WhiteNoise was > designed around the assumption that it's serving a set of > developer-supplied, public files which remain unchanged during the lifetime > of the process. This simplifies a lot of performance and security concerns > that come with serving mutable, user-supplied files. At present, if you use > `add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)` as you > suggested then WhiteNoise won't pick up any files that were uploaded after > the application was started -- at least, not unless you enable the > "autorefresh" setting which I explicitly don't recommend for production. > > Obviously it's possible to support this if we decide this is an important > goal but it will need more thought and will definitely be more work than > just supporting static files. > > On Tuesday, 29 December 2015 00:36:06 UTC, Tim Graham wrote: >> >> I'd like to work together with Dave to develop a proof of concept that >> integrates whitenoise into Django. I spent about an hour looking through >> whitenoise and our own static file serving code, and I think integrating >> whitenoise will yield a simpler user experience with about the same amount >> of code as have now. >> >> Essentially, we'd recommend adding something like this to existing >> wsgi.py files (it would be in the default startproject template) >> >> from whitenoise.django import DjangoWhiteNoise >> application = DjangoWhiteNoise(application) >> application.add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL) >> >> which would have the benefit of working out of the box in production too, >> I think. Of course, you could disable that based on settings.DEBUG or some >> other toggle. >> >> We could then deprecate: >> >> * django/contrib/staticfiles/views.py >> * django/contrib/staticfiles/management/commands/runserver.py >> * django/contrib/staticfiles/handlers.py >> * django/views/static.py >> >> Any objections to doing further investigation in this area? >> >> On Saturday, June 20, 2015 at 8:09:11 AM UTC-4, David Evans wrote: >>> >>> On Friday, 5 December 2014 19:14:29 UTC, Carl Meyer wrote: On 12/04/2014 10:33 PM, Collin Anderson wrote: > Hi All, > > I'm pretty interested in getting secure and _somewhat_ efficient static > file serving in Django. > > Quick history: > 2005 - Jacob commits #428: a "static pages" view. Note that this view > should only be used for testing!" > 2010 - Jannis adds staticfiles. Serving via django is considered "grossly > inefficient and probably insecure". > 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn. > 2012 - Aymeric adds StreamingHttpResponse and now files are read in chunks > rather than reading the entire file into memory. (No longer grossly > inefficient IMHO.) > > I propose: > - Deprecate the "show_indexes" parameter of static.serve() (unless people > actually use it). > - Have people report security issues to secu...@djangoproject.com (like > always) > - Audit the code and possibly add more security checks and tests. > - add wsgi.file_wrapper support to responses (5-line proof of concept: > https://github.com/django/django/pull/3650 ) > - support serving static files in production, but still recommend > nginx/apache or a cdn for performance. > - make serving static files in production an opt-in, but put the view in > project_template/project_name/urls.py > > I think it's a huge win for low-traffic sites or sites in the "just trying > to deploy and get something live" phase. You can always optimize later by > serving via nginx or cdn. > We already have the views, api, and logic around for finding and serving > the correct files. > We can be just as efficient and secure as static/dj-static without needing > to make people install and configure wsgi middleware to the application. > We could have staticfiles classes implement more complicated features like > giving cache recommendations, and serving pre-gzipped files. > > Is this a good idea? I realize it's not totally thought through. I'm fine > with waiting until 1.9 if needed. I also think this is a good plan. It certainly makes sense to look at
Re: Field localize useless
That's probably a poor example. Australian postcodes should be a StringField with a validation constraint ensuring that its 4 digits. Why? Well, there are australian postcodes that start with 0 - Northern Territory - and they're not going to be displayed correctly with ANY reasonable localisation feature. If any application requires a specific integer representation, then they're outside the scope of localisation and their display should be coded specifically. On Oct 19, 6:33 am, Michel Thadeu Sabchuk wrote: > > Consider as an example: Australian postcodes are 4 digit numbers. It's > > entirely reasonable that they might be stored as an IntegerField. But > > it would be completely inappropriate to display an Australian postcode > > withlocalize=True -- as "6,105", rather than "6105". -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
How do add ancillary, display-only data to each form in a formset?
I think I did my due google diligence (googlence?) on this one, and came up
short.
I'm trying to pass some ancillary, read-only information along with each
element in a formset. Ie, Along with the stuff that can be changed by the user,
I'd like some stuff that can-NOT be changed. Not all, but some, of the
information needs to be read back during validation.
For example, I have:
class Thingy ( models.Model ):
name = model.CharField ()
I have a few that selects a few Thingys and will present them to the user with
a checkbox next to each, so its obvious I want a form:
class CheckThingyForm ( forms.Form ):
checked = forms.BooleanForm ()
CheckThingyFormset = formset_factory ( CheckThingyForm, extra=0 )
Inside the view, I create a list of the thingies I want to present
thingies = Thingy.objects.filter ( ... some criteria... )
and now to... somehow... create the initial data for the formset. This is where
I am stumped. I've tried something like the following:
thingies_list = []
for thingy in thingies:
thingies_list.append ( { 'thingy': thingy } )
formset = CheckThingyFormset ( initial = thingies_list )
And while this presents the correct number of rows, my expectation on being
able to extract the thingy in the template fails. "form.thingy.name" returns
nothing
{% for form in formset %}
{{ form.checked }}{{ form.thingy.name }}
{% endfor %}
If I'm far more explicit about it, by using the following, i still turn up a
blank
thingies_list.append ( { 'name': thingy.name } )
What's the "right" way of passing ancillary data to a formset like this? If it
was just a single form, then I could very easily just pass the data i needed
through additional context variables. But since here I want to pass some data
per form, and dont care about being able to read it back or not, it makes sense
to try and pass it along WITH the form, and not need it to be a field itself to
read back.
(What I omitted was needing to pass thingy.id, so I know what thingy I'm
actually checking when validating the form... obviously I should include that
in the form or an "add_fields in the formset, and have it as a hidden... I
could do the same thing with the "name" and just extract the value explicitly,
but that's really contorted)
Thanks for reading this far... I hope someone can help.
--
("`-/")_.-'"``-._Chris Cogdon
. . `; -._)-;-,_`)
(v_,)' _ )`-.\ ``-'
_.- _..-_/ / ((.'
((,.-' ((,/ fL
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Vote on Jira as bugtracker
I used Jira at my previous company. It is a great tool, but it is _extremely_ heavyweight. Unless you need to high level of customisation of workflows and integrations it can provide, and have someone intimately familiar with it and/or have the nearly-full-time job of learning and fiddling with it [1], it will be an alienating, frustrating experience for all involved. [1] Just like about every Java-based tool out there. ;) -- 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/92a03cbc-fb14-4f89-ad5d-45ab77fcb207%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
