Re: Proposal: security enhancements
On Thursday, 3 May 2018 05:27:11 UTC+1, Josh Smeaton wrote: > > As Jacob mentioned, CSP can be quite scary, and sounds like something a > novice could try to implement for "good security" and end up causing way > more issues. > Perhaps documenting some of the new (and more accessible) CSP tooling available of late would help mitigate this? For example this Firefox addon that records a browser session and auto-generates an appropriate policy: https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/ On Thursday, 3 May 2018 05:27:11 UTC+1, Josh Smeaton wrote: > > I'd really like to see easy integration for report only mode > Agreed - particularly since django-csp dropped it's CSP report collection feature - and services like report-uri.com often require company privacy/legal sign-off, so are much more of a hassle to use. -- 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/ba75344d-1dcf-4085-bb62-ae4b4e3b8d83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Overhaul extra_requires to include more optional dependencies
Thank you for looking into this! Another benefit alongside ease of install and discoverability, is that it makes the requirements files of projects using Django more self-documenting (in that it avoids stray dependency entries that appear to be unused, but actually aren't - and so need a comment to explain what uses them). See also the related open ticket https://code.djangoproject.com/ticket/27682. Re the single package entries, I think there is still value in having them, so long as they are named by feature rather than by package name. eg `Django[crypto]` vs `Django[bcrypt]`. This allows the particular choice of library to be a Django implementation detail that can be adjusted without needing requirements file changes. Ed On Monday, 11 December 2017 10:26:11 UTC, jr...@leukeleu.nl wrote: > > Django has a number of optional features that require the installation of > additional Python packages. > > > Right now it's possible to $ pip install Django[bcrypt,argon2] to install > Django and the optional packages (at the correct minimum version) required > for bcrypt/argon2 support. > > > However this is not possible for other optional features, like > database/cache backend, gis, certain image related features etc. > > I've created a pull request adding the optional dependencies found in the > test requirements: https://github.com/django/django/pull/9440 / > https://code.djangoproject.com/ticket/28905 > > So end users can do things like: > > > $ pip install Django[mysql,sqlparse,images,memcached] > $ pip install Django[postgresql,gis] > $ pip install Django[selenium,test-parallel] > > > Not only would this make it much easier to install a particular > combination of Django and optional dependencies correctly, it also makes > some of the optional features/dependencies a little bit more discoverable. > This might not the full set of optional dependencies, or the right > grouping/naming, so a review is more than welcome (i.e. should sqlparse > be added to the mysql/oracle extra requirements? Should a sqlite extra be > added that only includes sqlparse?). > > Besides adding this to setup.py, additional changes to the documentation, > test instructions and scripts, code warnings etc. will probably be > necessary. > > If anyone objects to adding these extra requirements I'd also like to hear > about it. > -- 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/8cb27037-757b-4d19-893f-0e4cd83700c6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Default to BigAutoField
On Saturday, 10 June 2017 10:33:35 UTC+1, Claude Paroz wrote: > > Another idea is to leverage the system check framework (--deploy part) to > warn when the max id is over 50% of available range. > I was about to suggest the same. Seems like something worth doing regardless of whether we change the default (since it would help catch issues in existing installations who haven't yet migrated). Ed -- 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/fe0c7429-e9e9-406f-8701-8ebc550641e3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Implicit ForeignKey index and unique_together
I agree - #24082 is unrelated since it's PostgresSQL and text field specific, presumably resulting from: https://github.com/django/django/blob/8eb56f3c786b4dd7f78a60145ae2e483e24b62c1/django/db/backends/postgresql/schema.py#L34-L48 The issue in this thread is specific to the interaction between unique_together and a ForeignKey, where unless an explicit `db_index=False` is set on the foreign key, Django creates a redundant index (under MySQL at least, haven't checked the others). However this appears fixed on master - I thought originally it might have been inadvertently fixed by this refactor: https://github.com/django/django/commit/6bf7964023487f2a352084e74aca27aecb354d6c ...but that commit was backported to 1.10.x, and this reproduces on Django 1.10.3 so it can't be. (If anyone wanted to try and bisect, a reduced testcase is here: https://emorley.pastebin.mozilla.org/8933048) As mentioned below, the workaround is to add an explicit `db_index=False` to the `ForeignKey`, however if that's done to an existing `ForeignKey`, the migration actually drops and recreates the constraint rather than just dropping the index, which is pretty bad since the latter is an performed as an online DDL operation with InnoDB, whereas adding a constraint is not. As such, I've filed: https://code.djangoproject.com/ticket/27558 Best wishes, Ed On Saturday, 17 September 2016 01:48:15 UTC+1, Cristiano Coelho wrote: > > I think that the issue on Trac is actually something different, it talks > about the need (or not) of an index, when defining a unique constraint. > Most databases (if not all) will create an index automatically when a > unique constraint is defined, and correct me if I'm wrong, but PostgreSQL > (I don't about Oracle) is the only one that actually has constraints > (unique ones included here) and indexes as a separate thing, but for > SQLServer and MySQL the unique constraint is just an additional option of > the index. > > What Dilyan is talking about, and correct me if I'm wrong again, is about > the redundancy of defining an index on a foreing key, if you already have > that column as the left-most part of an index (unique or not). Most of the > time it will be redundant to have an index A, and another one (A,B), since > the latter will be also used for A queries. However this is up to debate > since using the (A,B) index can be potentially slower than using just the A > index due to the index being bigger, but you save space and > insert/update/delete performance for not having two different indexes. > > In my case, most of the time I end up with a db_index=False on foreing > keys that I know I have a index/unique defined somewhere else to avoid the > overhead of the additional index. > > El viernes, 16 de septiembre de 2016, 11:34:52 (UTC-3), Tim Graham > escribió: >> >> Did you try to find anything related in Trac? Maybe >> https://code.djangoproject.com/ticket/24082? >> >> I use this query in Google: postgresql unique index site: >> code.djangoproject.com >> >> On Friday, September 16, 2016 at 9:51:13 AM UTC-4, Dilyan Palauzov wrote: >>> >>> Hello, >>> >>> according to the documentation models.ForeignKeys creates implicitly an >>> index on the underlying database. >>> >>> Wouldn't it be reasonable to change the default behaviour to only create >>> implicit index, if there is no index_together or unique_together starting >>> with the name of the foreign key? In such cases the implicit index is >>> redundant, at least with Postgresql, as the value can be found fast using >>> the _together index. >>> >>> Greetings >>>Dilian >>> >> -- 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/2bc94b77-0b32-4df4-8d05-21e3c811b4a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Provide a simpler way to default runserver IP/port to 0.0.0.0:8000
This was filed as https://code.djangoproject.com/ticket/27537 , but moving here for discussion. We have the following use case: * An app uses a VM for the local development environment (eg via Vagrant). * It's required to be accessible from the VM host (either on it's own IP, or on localhost via eg Virtualbox port forwarding) to allow development to occur using editors/browsers on the host. (The configuration is such that connections are only allowed from the VM host and not other machines on the network, so this is still secure.) * The app has no need for nginx/apache, since production is Heroku (where that's discouraged) and so it uses gunicorn + WhiteNoise. * During development, devs want to use runserver rather than gunicorn for convenience (and familiarity for existing Django devs). * However `./manage.py runserver` doesn't work, since that binds to the loopback adapter of the VM guest OS only (127.0.0.1) and not 0.0.0.0. (This is a sensible default.) * Therefore `./manage.py runserver 0.0.0.0:8000` must be used, which: - is not immediately obvious to devs new to the project (which is open source, so we often have new contributors). Docs are great, but not everyone reads them fully - defaults that work out of the box are best. - means even once they realise the need for the explicit binding address, they have to type it out every time. Current workarounds are: a) Add an nginx/apache/varnish service to the VM to reverse proxy from 0.0.0.0:X to 127.0.0.0:8000, increasing bootstrap time and boilerplate. b) Not use runserver, and use gunicorn instead (where the `PORT` environment variable can be set, making it bind to `0.0.0.0:` [1]). c) Add bash aliases to the development environment (but then they're not immediately discoverable either, and break muscle memory for existing Django users). d) Write a custom runserver command that overrides the inbuilt one (but this requires overriding the `handle()` method, since `127.0.0.1` is hardcoded [2], so even more boilerplate). Possible changes that would make this easier: 1) Allow overriding runserver default IP/port using Django settings. 2) Allow overriding runserver default IP/port using environment variables (like `PORT` already supported by gunicorn, that defaults the IP to `0.0.0.0` too). 3) Move the hardcoded `127.0.0.1` string [2] to an attribute on the `Command`, like `default_port` is, to at least reduce the boilerplate for overriding using a custom runserver command. I can imagine (3) would be more likely to be accepted, however it would still mean we have to override runserver, so (1) or (2) would be preferred. I'm happy to implement this - it would just be helpful to know people's thoughts before I open a PR. Many thanks :-) Ed [1] https://github.com/benoitc/gunicorn/blob/6eb01409da42a81b7020cd78c52613d8ec868e94/gunicorn/config.py#L543-L544 [2] https://github.com/django/django/blob/eb42d8d5d9b0968ce12d09760afff684bee56a3a/django/core/management/commands/runserver.py#L95 -- 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/1f272641-1fbd-4b0a-8f45-b757c0d2b975%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
