Re: Thoughts on diff-based migrations with django?

[Florian Apolloner]

Just for one migration; but there is the sqlmigrate management command 
which you can use as building base.

Cheers,
Florian

On Wednesday, May 2, 2018 at 7:07:27 AM UTC+2, djrobstep wrote:
>
> Bump! Is there a documented way to generate the from-scratch creation SQL 
> for the currently defined models? If not, is it possible to add something 
> that spits this out? Happy to take a look at implementing this.
>
>
> On Sunday, 25 February 2018 13:48:27 UTC+11, djrobstep wrote:
>>
>> Yes, I don't think it would make sense to include in django directly. 
>> Because the diffing approach works at the database directly, below the 
>> layer of the models, the two parts don't really need to be integrated. All 
>> that is really required for django to support this as an option is to 
>> provide a documented way to emit the from-scratch creation SQL for the 
>> currently defined models.
>>
>> As far as I can tell there used to be an admin command available for this 
>> in version 1.x but it was removed? Is there already another supported way 
>> to do this?
>>
>> Incidentally, I've used this approach on some larger projects with 
>> diverging branches and it worked pretty well. You do have to set some 
>> things up differently tho - keep meaning to write a blog post or something 
>> about this. The need to have access to a production schema is an additional 
>> hurdle, but well worth it for the additional testability and robustness, in 
>> my experience.
>>
>> On Wednesday, 21 February 2018 18:44:30 UTC+11, Andrew Godwin wrote:
>>>
>>> Hi,
>>>
>>> This was an approach we deliberately avoided during development of the 
>>> current migration system - it works poorly with diverging feature branches 
>>> and requires that your developers have access to production schema at all 
>>> times (and additionally that you don't have divergent production/staging/QA 
>>> deploys, like many environments do).
>>>
>>> I think it would be a fine addition as an optional third-party tool, but 
>>> it's not something that really makes sense to include in Django at this 
>>> point I think.
>>>
>>> Andrew
>>>
>>> On Mon, Feb 19, 2018 at 10:05 PM, djrobstep  wrote:
>>>
 Hi all,

 Some thoughts on schema migrations that may interest you. By way of 
 background, I'm the author of migra (https://github.com/djrobstep/migra), 
 a schema comparison/diff tool for Postgres.

 I initially wrote this tool because I wanted to be able to generate 
 migration scripts automatically, without needing historical migration 
 files.

 It means that you can do things like sync your database to your models 
 mostly automatically, and also explicitly test for a matching schema. 
 Instead of a chain of migration files you only ever need to keep track of 
 one, containing any pending changes).

 I've used this approach with success on a number of projects now, and 
 it seems to work pretty well. I also talked about this approach to 
 migrations at the most recent PostgresOpen (
 https://www.youtube.com/watch?v=xr498W8oMRo).

 The downside of this approach is that it's slightly more operationally 
 complex (you need have a temporary copy of your production schema 
 available 
 for comparison purposes, typically a --schema-only dump file) and also 
 that 
 it's postgres-only at this point. It's also conceptually quite different 
 to 
 the typical Django/Rails style of migrations which represents a barrier to 
 entry.

 In spite of this, I think doing migrations this way has some compelling 
 advantages, that are relevant to users of Django.

 I'm interested in your opinions on this topic as Django developers. 
 What do you think? Is it something worth offering as an option for 
 managing 
 Django migrations? If your feelings are positive, I'm happy to take a look 
 at extending the code accordingly.

 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/5f84157b-071e-42c3-90dd-6f9e3df48ab3%40googlegroups.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 

Schema alter_field - check constraints

[Maximiliano Robaina]

Hi,

Digging into schema migration code (and updating this to work with Firebird 
[1]) I see in _alter_field method [2] a validation for  Change check 
constraints?
Of course, this fails related to the test method 
"test_alter_field_default_dropped" because in Firebird check contraints are 
table based and not column based.
Then, there is a feature property "supports_column_check_constraints", now 
the question is Should not we use that feature to validate if is necessary 
check the number of check constraints?

If supports_column_check_constraints is False no validation is necessary, 
right?


Regards

[1] https://github.com/maxirobaina/django-firebird
[2] 
https://github.com/django/django/blob/4660ce5a6930e07899ed083801845ee4c44c09df/django/db/backends/base/schema.py#L593

-- 
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/1f16ac9b-7d6c-450e-a662-9aa616271a78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: security enhancements

[Josh Smeaton]

Most of this sounds really good. 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. I'd really like to see easy 
integration for report only mode, with controls that are harder to turn for 
full blown CSP.

With regard to pyup - the pipenv check command handles this nicely. I'd 
imagine support would be similar - in that we'd list pyup as a required 
dependency for Django, and ship a management command that uses it. The 
deploy check could then hook in.

On Tuesday, 1 May 2018 17:28:21 UTC+10, James Bennett wrote:
>
> I've written this up in pseudo-DEP format partly for ease of
> organization, and partly because I'm unsure whether it would require a
> DEP. Right now I'm just throwing it out here as a proposal, and
> offering to work on implementing it; if you have questions, concerns,
> or suggestions for things to add to it, please let me know :)
>
>
> Introduction
> -
>
> Django has acquired a reputation for being helpful with/good at
> "security". Which has been a focus since at least 1.0; Django goes out
> of its way to protect you out of the box against common security
> problems, and includes a lot of tools geared toward making it easy to
> do the right thing when building apps.
>
> But security is a Red Queen problem; we can't ever pause and rest,
> since as soon as we do we'll fall behind.
>
> In light of which, I'd like to propose a few security-related
> improvements/additions, and offer to put in the time to help implement
> them. My baseline goal here is to set things up such that it's
> possible, using only things that ship with Django itself and an
> SSL-enabled hosting service, to score an A+ rating on
> securityheaders.com. Beyond that, some stretch goals are possible.
>
>
> Content Security Policy
> 
>
> CSP[1] is one of the more important defenses available against XSS and
> a few other types of attacks. Django does not currently have
> out-of-the-box support for it; the usual solution is to install
> django-csp[2], configure it and set up its middlware to emit the CSP
> header.
>
> I'd like to see support for CSP built in to Django. This could be done
> by integrating django-csp, which is open source and uses a compatible
> license, though there'd need to be some updates to its documentation
> (which seems to lag a bit behind what the code supports) and it might
> also be good to switch over to using dictionary-based configuration.
>
>
> Referrer-Policy
> -
>
> The Referrer-Policy header[3] is relatively new, but gaining support
> in major browsers. It helps enhance both security and privacy.
>
> I wrote a package earlier this year[4] that supports sending the
> Referrer-Policy header, and BSD-licensed it. It would be relatively
> easy to integrate this into Django.
>
>
> Subresource integrity
> -
>
> Subresource integrity[5] allows the author of an HTML document to
> supply the expected hashes of resources (scripts, stylesheets, images,
> etc.) referenced in the document. This helps to harden against not
> only local breaches, but also breaches of third-party scripts and
> CDNs.
>
> I don't have a clear vision yet of how it would work, but I'd like to
> see the form media system and the staticfiles app grow support for
> SRI. In the case of form media, the output already generates the full
> HTML and could include the hash. In the case of the {% static %}
> template tag, I'm open to suggestions for how it could
> generate/include the hash. The admin should use this by default.
>
>
> CORS
> -
>
> Cross-Origin Resource Sharing is increasingly important on the modern
> web, and Django does not currently support setting CORS headers. There
> is an open-source package for CORS in Django[6], which could be
> integrated.
>
>
> rel="noopener"
> -
>
> Setting rel="noopener" on links which will open in new tabs/windows is
> an easy way to head off certain types of surprising attacks[7]. Like
> SRI, I don't yet have a great plan for how this could be supported
> easily/automatically in Django, but I'd like to give it a try.
>
>
> Improved system-check integration
> ---
>
> Currently the security system-check is OK, but still a bit
> minimal. I'd like to add support for checking at least everything I've
> proposed adding above, and probably several more items. In my ideal
> world, a service like securityheaders.com could be replicated by the
> security check.
>
> In my magical stretch-goal land, I'd also figure out a way to support
> the pyup safety library[8] to scan for a requirements file and any
> dependencies in setup.py, and warn if known-insecure versions are
> specified.
>
>
> Improved security documentation
> -
>
> Right now we have OK documentation on security, in that we h