81–90 of 136 posts
Haven't read more than 50 pages yet but I like it. Great job!
I haven't been working with django recently and having completely read the book, I am now up to date.
* The book has a lot of practical advice having developed using django for years. For example, the book recommends, whenever you have a custom manager, always explicitly define `objects` as the default manager, before the custom manager.
* The book makes a recommendation; but also mentions alternatives where applicable. The authors prefer a 3 tier project layout but also suggest that a lot of people prefer the 2 tier layout where the `manage.py` is in the root of the repository. Similarly in the chapter on the Class Based Views. The book suggests an approach and also includes other ones.
* Includes the latest and the new changes in the django 1.5 wrt the User model and how to inherit.
* Recommends and suggests many good third party applications. More books need to do this.
* Provides good review material (if you already know) about Security, Deployment, performance etc.
All of this, just over the top of my head.
Real world advice is often hard to come by. Whether you are a professional or a novice or just checking out django, you should buy this book.
Considering purchasing since I was thinking of diving into django for my next project.. If I buy the PDF now, and you eventually release an EPUB or other format, will I get access to those files (with updates) as well?
Honestly, I don't know enough about ePub distribution to answer you. I would love to do that though.
Earlier quoted context omitted.
I don't think the 2nd point has significant performance implications. If you're not serving up static pages then there's always network calls to be made on the backend. Storing a nonce on the client and looking everything up on the backend is an easy solution which means you don't have to worry about what data you're storing and if that'll be available in the browser. I think it's cheaper to optimize on the backend f…
Thank you - my thoughts too I cannot trust anything returned from a client so it seems best to Only return one thing from the client As for a carefully vetted security pro - that's great but I am looking for basic generic best practises (we know that has evolved from md5 hashes to bcrypt but what else is there?) It seems either a hole in my education or a hole in general common knowledge
It's good to understand why it does the things it does, but without a certain amount of trust in the framework, you can lose a lot of it's advantages.
One of my big concerns is user / session security. I have tried to follow and reason through discussions on stackoverflow and much of tpatchek's notes. I would be interested in how "high level" the security chapter is from anyone who has shelled out already. For example I assume I will 1. only use persona or openid (avoids storing passwords in my servers thus making a lot of things much much easier) 2. sessions - sto…
1. Using recent django (1.4+) will get you _very good_ password storing security. Use HTTPS and you're "as good as anybody else". no persona/openid needed 2. Django has signed cookie sessions (optional to be used) and a solid signing library. This ensures that the data that is returned is the same as the data that was stored. This doesn't mean that a cookie can't be hijacked, so you should take care to have acceptabl…
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.
Earlier quoted context omitted.
1. Using recent django (1.4+) will get you _very good_ password storing security. Use HTTPS and you're "as good as anybody else". no persona/openid needed 2. Django has signed cookie sessions (optional to be used) and a solid signing library. This ensures that the data that is returned is the same as the data that was stored. This doesn't mean that a cookie can't be hijacked, so you should take care to have acceptabl…
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.
Congratulations! If I may suggest a few things: - How about adding a sample in the web page? - You may to consider using PayPal in addition to Gumroad. Gumroad is awesome, but some people may only be able to use PayPal (e.g. no International Credit Card) or prefer it. I use both for my book and I sell way more copies on PayPal.