Django meetup Amsterdam 18 May 2016¶

Reducing boilerplate with class-based views - Priy Werry¶

A view can be more than just a function. They can also be class based, django has quite a lot of them. For example the TemplateView that is very quick for rendering a template. Boilerplate reduction.

Django REST framework is a good example of class based views usage. It really helps you to reduce the number of boring boilerplate and concentrate on your actual code.

Examples of possible boilerplate code:

• Parameter validation.

• Pagination.

• Ordering.

• Serialisation.

They wanted to handle this a bit like django’s middleware mechanism, but then view-specific. So they wrote a base class that performed most of the boilerplate steps. So the actual views could be fairly simple.

It also helps with unit testing: normally you’d have to test all the corner cases in all your views, now you only have to test your base class for that.

Custom base classes also often means you have methods that you might re-define in subclasses to get extra functionality. In those cases make sure you call the parent class’s original method (when needed).

Users of your views (especially when it is an API) get the advantage of having a more consistent API. It is automatically closer to the specification. The API should also be easier to read.

Meetups on steroids - Bob Aalsma¶

“Can I get a consultant for this specific subject?” Some managers find it difficult to allow this financially. A special course with a deep-dive is easier to allow.

He would like to be a kind of a broker between students and teachers to arrange it: “Meetups on steroids: pick the subject - any subject; pick the date - any date; pick the group - any group”

Security in Django - Joery van der Zwart¶

Joery comes out of the security world. He doesn’t know anything from the inside of django, but a lot of the outside of django. He’s tested a lot of them.

Security is as strong as its weekest link. People are often the weakest link. Django doesn’t protect you if you explicitly circumvent its security mechanisms as a programmer.

Django actually protects you a lot!

A good thing is to look at the OWASP list of top 10 errors. (See also Florian Apolloner’s talk at ‘Django under the Hood’ 2015, for instance).

• SQL injection. Protection is integrated in django. But watch out when doing raw sql queries, because they are really raw and unprotected. If you work through the model layer, you’re safe.

• Authentication and sessions. Django’s SessionSecurityMiddleware is quite good. He has some comments on authentication, though, so he advices to do that one yourself. (Note: the local core committer looked quite suspicious as this was the first he heard about it. Apparently there are a number of CVEs that are unfixed in Django. Joery will share the numbers.)

• XSS injection. User-fillable fields that aren’t escaped. Django by default… yes, protects you against this. Unless you use {% autoescape off %}, so don’t do that.

• Direct object reference. He doesn’t agree with this point. So ignore it.

• Security misconfiguration. Basically common sense. Don’t have DEBUG = True on in your production site. Django’s output is very detailed and thus very useful for anyone breaking into your site.

• Sensitive data. Enable https. Django doesn’t enforce it. But use https. Extra incentive: google lowers the page ranking for non-https sites…

• Access control. It is very very very hard to get into Django this way. He says django is one of the few systems to fix it this rigidly!

• CSRF. Django protects you. Unless you explicitly use @csfr_exempt…

• Known vulnerabilities. Update django! Because there have been fixes in django. Older versions are thus broken.

• Insecure forwards/redirects. Once you’ve enabled django’s default middleware, you’re secure.

So Django is quite secure, but you are not.

Look at django’s security documentation. And look at https://www.ponycheckup.com. You can check your site with it. The good is that it is simple. It only checks django itself, though.

With some other tools (like nessus) you have to watch out for false positives, though. So if you don’t know to interpret the result, you’ll be scared shitless.

A good one: Qualys SSLlabs https checker to get your ssl certificate completely right. (Note: see my blog post fixing ssl certificate chains for some extra background.)

“Owasp zap”: open source tool that combines checker and reduces the number of false positives.

The summary:

• Good: django with middleware.

• Good: django provides a good starting point.

• Bad: experimenting. Be very sure you’re doing it right. Look at documentation.

• Bad: do it yourself. Most of the times.

Django girls Amsterdam¶

On 25 june there’ll be a django girls workshop in Amsterdam. Everything’s set, but they do still need coaches.