Hi Christopher, Overall, this looks like a great project and I look forward to the more flexible validation hooks. As the author of django-secure, I do have one concern with the implementation plan:
Django's existing validation checks are intended to be run in development, as a debugging aid, but not in production (to avoid any slowdown). Thus, by default they are run prior to many management commands (such as syncdb, runserver), but are generally not run on production deployments. The checks in django-secure, on the other hand, are intended to be run only under your production configuration, and are mostly useless/wrong in development. Since runserver doesn't handle HTTPS, most people don't use HTTPS in development, which means you can't set e.g. SESSION_COOKIE_SECURE to True in development or your sessions will break, which means that django-secure check will fail; same goes for most of the other checks. Running django-secure's checks every time you syncdb or runserver in development would be at best a waste of time and at worst extremely annoying. So I think the validation framework you build has to incorporate some kind of distinction between these two types of validation, which have very different purposes and should be run at different times: development/debugging validation and production-configuration validation. I'm not sure exactly what form this distinction should take: perhaps validators are simply tagged as one type or the other and then there are two different management commands? Interested in your thoughts, Carl -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
