91–100 of 136 posts
The actual content of this book is excellent though. I feel like I keep up with new developments in the Django community pretty well, but there's a lot of advice in this book I hadn't heard before.
Does it mostly focus on Django on Python 2, or is there a good portion that deals with Django on Python 3 as well?
Since the book is focused on Django 1.5, which only experimentally supports Python 3, it would be difficult for the authors to focus on Python 3 without a ton of caveats and/or issues for readers.
Django 1.6 will bring "official" support for Python 3.2.3 and 3.3[1]
[1]: https://docs.djangoproject.com/en/dev/faq/install/#can-i-use...
Is there anything like this but for Flask?
# Normally you should not import ANYTHING from Django directly
# into your settings, but ImproperlyConfigured is an exception.
from django.core.exceptions import ImproperlyConfigured
This is a really great book. The formatting does need a lot of work (I see no chapter or section headings in the PDF) and an ePub version would be very useful. The actual content of this book is excellent though. I feel like I keep up with new developments in the Django community pretty well, but there's a lot of advice in this book I hadn't heard before.
There are chapter and section headers in the book, but we've had a couple people using PDF readers on Linux who don't see them. Can you email me at pydanny@cartwheelweb.com and let me know which PDF reader you are using so we can test and hopefully fix the issue?
Thanks!
I did purchase this because I will find it very useful, but I do want to say that providing an ePub format is clutch. Please, please do what you can to provide this format in the future!
Earlier quoted context omitted.
It does use the 'do fancy things with HMAC signed tokens' to handle password reset though, which (as a general scheme) has been criticised vs the 'store random dumb token, details in the DB' method, for being difficult to do right and open to subtle flaws. Obviously I'm not aware of any Django-specific issues with it (or I'd have reported them already), but it's a design decision I've wondered about.
Any details on the criticism? All curiosity for me at this point.
It boils down to "possible, but very easy to screw up, and for what is probably relatively small benefit."
The only benefits I can think of for the info-in-token approach are:
* Less database hits to validate a token. Given that password resets are probably only a small part of your site load, I'm dubious as to the utility of this optimisation.
* No server-stored tokens to secure - If an attacker manages to dump or partially break your database (SQLi, logic bug, whatever), they could extract the reset tokens and use them to gain access. Obviously, a full db exploit would make this unnecessary, and a proper reset implementation (that expires the tokens after use, sends confirm emails on use, etc) means unauthorised use would hopefully be detected.
In the info-hash-token, the only place it's ever actually stored is in the user's mail-box (and every email server involved in the process along the way, potentially), which might reduce the risk of disclosure, especially bulk (server dump) disclosure.
Any other advantages I might have missed? It's possible to do things like token expiry, invalidate on use, invalidate outstanding tokens using hashed tokens, but all of those things are fraught with danger.
One tiny annoyance is the lack of pre-generated bookmarks based on the contents page. See [1] for example of how Uncle Bob's clean code PDF ships with these (my PDF reader is Foxit). These bookmarks save a hell of a lot of time navigating back and forth in a large PDF document such as books.
