Hello!
**Making distinction between form validation and static validation.** I
named
the process of static checks of apps, models etc. "validation".
Unfortunately,
novices may confuse it with form validation. So I propose to rename it to
"verification". Functions/methods/classmethods (referred to as just
functions)
starting with `validate_` will start with `verify_` now. And functions
discovering all other verification functions will be called `verify` instead
of `validate_all`. This is shorter than `validate_` (only 6 letters) and
there
is no risk of confusing novices. I considered alternatives: "check" is too
general and "static_check" as well as "static_validate" are too long.
**Disabling/enabling parts of verification**
> 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
DEBUG setting is a hint about the environment; if you are working in
development environment, then it's likely that DEBUG is set to True; and you
have DEBUG set to False in production, I hope. By default, `verify_*`
functions will be run only when DEBUG is set to True. django-secure checks
will be decorated with new `run_only_in_production` decorator and will run
only when DEBUG is set to False.
However, I'm not sure if this is the best solution. There are some
disadvantages, i. e. I can imagine people saying "what to do if I want to
run
security checks while DEBUG is set True?". Of course, they can set DEBUG to
False, but it's only a workaround. I afraid that it's only tip of the
iceberg
-- we will probably need more control over which checks to run.
An another solution, much more flexible, is to pass around a "filter
function"
which takes a `verify_*` function and says if the function should be
called. A
drawback is that this forces developers to add an argument to every
`verify_*`
function even though they don't want it. In order to avoid that we can
introspect the function and check if the function requires `filter` argument
and in that case call it without any argument, otherwise call it passing the
filter function as `filter` argument, but this is hacky, ugly and
non-pythonic; and if anybody wants to rewrite `verify` function (which
collect
all `verify_` functions and run them), they need to know about that trick
and
how to use it.
So we can split `verify_` functions into two groups: one which does the
checks
and doesn't require the filter function and another one which finds all
`verify_` functions and run them. An example of the former is
`verify_upload_to_attribute` of `FieldFile`; and an example of the latter is
`verify` function. The latter requires the filter function as an argument.
We
need to come out with name pattern for the former (I have no idea now, I
will
propose something tomorrow). This is the most flexible solution, but it
increases complexity.
I prefer the last, most flexible solution.
**Breaking points.** As Russell suggested me during private conversation, I
will
try to merge my branch as often as possible. That should increase chance of
success. There is one obvious breaking points: after finishing revamping
validation.
Merging while working on the framework shouldn't be too hard. That is
because
I will refactor bottom-up and keep all code and tests running and because I
won't touch any public API. Actually, merging can be done after every week.
First question: Django 1.6 is being released now and there is no 1.7
branch yet; will be there any 1.7 branch where I can merge to?
Another issue is if we can merge a branch when documentation is not
finished.
I will create a new doc page at 3rd week and I will be completing it to the
end of 8th week. I guess that it's not allowed to merge code with partial
doc.
A solution may be to merge code without doc and merge the doc only at the
end.
My schedule didn't change, but I will paste it here:
1. Rewriting tests of field validation (1 week)
2. Rewriting field validation (1 week)
3. Writing documentation (mainly overview) (0.5 week)
4. Tests, implementation and documentation of models validation (1 week)
5. Tests, implementation and documentation of apps validation (1 week)
6. Rewriting validation of custom User model (0.5 week)
7. Tests, implementation and documentation of manager validation (0.5
week)
8. Rewriting validation of AdminModel and its tests (1 week)
9. Rewriting mechanism of triggering validation framework (1 week)
10. Finishing documentation (0.5 week)
I would like to make the first merging after the first week (rewriting
tests of
field validation), because it will make me familiar with the process of
merging and will make next merging (which will be much bigger) easier. The
first week is only refactoring, no doc, no new features, so I guess it can
be
merged.
If doc is not a problem then we can merge after 3. task (field validation
implemented) and after 6. task (models and app validation implemented). And
of
course, in the end.
If it comes to the second part of my project (merging django-secure), it's
obvious there is only one merging point. :)
**Some changes to public API.** On last Friday (7 June 2013) I gave a small
talk
about my project at pykonik (a meeting of Python programmers in Kraków
where I
live). I was given some feedback.
I changed fields of Error and Warning classes. Previously I proposed
splitting
error message into `msg` (short error message), `explanation` (why is some
situation disallowed?) and `hint` (list of solutions). We agreed that
`explanation` is redundant, so now I propose only two fields: `msg` and
`hint`. `hint` will be optional, so you can set it to None, but you have to
do
it explicitly:
Error("something is broken", hint=None)
I hope that this will force developers to thing carefully if they cannot
give
any useful hint and that it will improve quality of error messages.
**django-security** During the meeting, somebody referred to
django-security [1],
and I will have a look at it soon. Implementing some features of
django-security
may be a good idea if I finish merging django-secure earlier.
[1] https://github.com/sdelements/django-security
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
