Re: Add documentation to address OWASP Top 10?

That was my thinking as well. This is a basic topic when it comes to web security. We can point to the OWASP 10 but I don’t think it’s reasonable cram a complete course about web security into Django’s documentation, let alone maintain it. Django’s docs will never contain everything one may

Re: Add documentation to address OWASP Top 10?

On 06/04/16 11:35, Josh Smeaton wrote: I like the idea of addressing the OWASP top 10. Further, I think the advice of obscuring keys is wrong. The problem is actually addressed in the OWASP Top 10[0] *4 Insecure Direct Object References:* A direct object reference occurs when a developer

Re: Add documentation to address OWASP Top 10?

> Den 6. apr. 2016 kl. 07.29 skrev Anssi Kääriäinen : > > It is notable that if the number of items is a secret (say, you don't > want to reveal how many sales items you have), just having information > about sequential numbers is bad. In that case you should use UUID, >

django-firebird for django 1.8.x alpha

The current master branch is being developed under django 1.8.x This is still in alpha status but I think the base code works pretty well. Any feedback wiil be appreciated. https://github.com/maxirobaina/django-firebird/commits/master -- You received this message because you are subscribed

Re: New `pre_handler()` method on Class-Based Views

Too bad the issue was already closed. I’ve added my 2 cents: https://github.com/django/django/pull/6416#issuecomment-206301186 I’d expect having a View.setup() method would simplify things for both simple use case and complex projects. Best, Diederik > Op 5 apr. 2016, om 15:20 heeft Tim

Re: Vendoring multipledispatch

Does anyone (potentially from OS packaging worlds maybe) have a good reason NOT to have a dependency? In the event that Django does have Pip dependencies, I still think we should establish some rules. Things like they should be stable and mature, and perhaps widely known, and still be under

Vendoring Select2

Hi, as promised I started working on an autocomplete field for `django.contrib.admin` as a more convenient alternative to `row_id_fields`. We had a longer discussion in the ticket and also at the sprints at DjangoConEU with some of the maintainers for famous 3rd party autocomplete

Re: Vendoring Select2

Hi All, I'm in favor of this change. This has the potential to replace the raw_id_fields and filter_horizontal which I think would be a huge win. Those widgets are out-dated not only in terms of code, but also from a UI point of view. I'll try to give my answers to some questions before they

Re: Vendoring Select2

I’m OK with this. It's a reasonable solution. -- Aymeric. > On 06 Apr 2016, at 15:25, Johannes Hoppe wrote: > > Hi, > > as promised I started working on an autocomplete field for > `django.contrib.admin` as a more convenient alternative to `row_id_fields`. > > We

Re: Vendoring Select2

Agreed. I recently was trying to use a fitler horizontal widget on my phone and thought the whole thing was broken because `` looks so wrong. I'd love to see this experience improved, and select2 is a good reliable solution. On 6 April 2016 at 15:11, Aymeric Augustin <

Re: Vendoring Select2

In previous projects (before moving to rolling my own UI components), I ended up favouring Selectize (http://selectize.github.io/selectize.js/) after getting fed up with Chosen and Select2 - but this was a few years ago and I can't remember my reasons. But if it hasn't been considered, it might be

Re: Vendoring Select2

I understand that. Select2 used to be horrible before the version 4 release. Selectize was on the table, but dropped because it doesn't allow configuration via `data`-attriburtes. We wanted to keep the JS party as minial as possible. Select2 does a good job since version 4, you can configure

Re: django-firebird for django 1.8.x alpha

hi. i will make some testes with firebird 2.0.5 and access to comercial software lojafacil that use firebird. thanks for message. 2016-04-06 8:13 GMT-03:00 mariuz : > The current master branch is being developed under django 1.8.x > > This is still in alpha status but I think

must we include the source files for all minified JavaScript?

>From a Trac ticket [0]: In Debian, we like to have the sources of everything that we ship and we consider that minified javascript files are not really scripts (which are their own source). There are currently two problematic files in Django: js_tests/qunit/blanket.min.js

Re: must we include the source files for all minified JavaScript?

It seems like a reasonable request to me. It's just generally useful to have the original source matching the minified code available, e.g. for debugging an issue with that code. In theory you can go find the corresponding non-minified code yourself, but it's not always easy to find exactly the

Re: Add documentation to address OWASP Top 10?

Proposed text: Take a look at the Open Web Application Security Project (OWASP) Top 10 list which identifies some common vulnerabilities in web applications. While Django has tools to address some of the issues, other issues must be

Re: Vendoring multipledispatch

The only problem I can see is dependencies conflicts, where Django would need package X version > 1.0 and another installed package would need package X version 0.9. I have this issue with a project of mine that required six >= 1.10 and for some reason Xcode on OSX with the system Python (ie. not