In order to get more attention, I've created a new thread [1].
[1] https://groups.google.com/forum/#!topic/django-developers/_sde4eoNRyQ
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emai
On Sun, 2013-09-15 at 18:23 +0200, Aymeric Augustin wrote:
> On 15 sept. 2013, at 17:57, Simon Kern wrote:
>
> > Yes but management commands should be irrelevant for django-secure
>
> Well, in this case, I have a backup argument :)
>
> There's a non-negligible number of people serving webs
On 15 sept. 2013, at 20:07, Michael Manfre wrote:
> No amount of code or docs will fix all of the stupid things people do.
>
Of course, but that isn't a sufficient reason for disabling the security
checks. The point of django-secure is to help users with limited knowledge of
security best pract
On Sep 15, 2013 12:23 PM, "Aymeric Augustin" <
aymeric.augus...@polytechnique.org> wrote:
>
> On 15 sept. 2013, at 17:57, Simon Kern wrote:
>
> > Yes but management commands should be irrelevant for django-secure
>
> Well, in this case, I have a backup argument :)
>
> There's a non-negligible
On 15 sept. 2013, at 17:57, Simon Kern wrote:
> Yes but management commands should be irrelevant for django-secure
Well, in this case, I have a backup argument :)
There's a non-negligible number of people serving websites in production with
./manage.py runserver, in spite of all the warnin
Yes but management commands should be irrelevant for django-secure
Am 15.09.13 17:52, schrieb Aymeric Augustin:
> On 15 sept. 2013, at 16:40, Simon K. wrote:
>
>> But in production the entry point is the wsgi.py file, isn't it?
> It's the main entry point in production, but not the only one;
On 15 sept. 2013, at 16:40, Simon K. wrote:
> But in production the entry point is the wsgi.py file, isn't it?
It's the main entry point in production, but not the only one; manage.py /
django-admin.py is still used to run management commands.
--
Aymeric.
--
You received this message be
Am Mittwoch, 17. Juli 2013 10:20:47 UTC+2 schrieb Russell Keith-Magee:
>
>
> On Mon, Jul 15, 2013 at 8:17 PM, Christopher Medrela
>
> > wrote:
>
>> Progress: I've implemented manager checks.
>>
>> This API allows us to register, among other things, app-specific checks.
>> But
>> it's not necessa
>
> 4. More important changes in code:
>>
>> - Introduced RAW_SETTINGS_MODULE [1]. I use it in compatibility checks to
>>> test
>>
>> if `TEST_RUNNER` setting was overriden [2].
>>
>>
>
> Have a look at the internals of the diffsettings management command -- I'm
>> not sure RAW_SETTINGS_MODU
>
>
> We probably cannot move checks of `primary_key` and `unique` living in
> `FileField.__init__`. We test if one of these two parameters was passed; we
> don't check their values. Consider that an user passes unique=False. This
> is
> the default value, but nevertheless, this should result in
I've written four more tests. I've moved some of checks out of `__init__`
methods. I've changed `tag` to `register`. I've rebased against master. I've
improved documentation (added sections about filtering and silencing system
checks), but I'm still polishing it. Code is ready for final review exce
Hi Christopher,
On Tue, Sep 3, 2013 at 9:25 PM, Christopher Medrela wrote:
> 1. Progress: I've made improvements to admin checks. I've also finished
> implementing filtering and silencing checks. I've rebased my branch against
> master again.
>
> Excellent - I'll take look and get you some feedb
1. Progress: I've made improvements to admin checks. I've also finished
implementing filtering and silencing checks. I've rebased my branch against
master again.
2. I'm afraid that there is too little time to merge django-secure.
September 16 is
suggested 'pencils down' date, so there are only le
Hi Chris,
On Wed, Aug 28, 2013 at 5:16 AM, Christopher Medrela <
chris.medr...@gmail.com> wrote:
> 1. One of my questions left unanswered on the pull request [1] (I mean
> this one
> about documentation and `__str__` use.).
>
I've left a comment on the pull request, I've given the same comment i
1. One of my questions left unanswered on the pull request [1] (I mean this
one
about documentation and `__str__` use.).
2. I've finished rewriting admin checks. I've renamed `admin_validation` to
`admin_checks`. I would like you to have a deep look at `fk_name` and
`exclude` checks [2] as well a
Progress:
- Converted `BaseCommand.verbosity` from bytestring into an unicode.
- Integrated compatibility checks.
- Deprecated "validate" command. This command delegates to "check" command
now.
Changed "check" command -- it performs all system checks, including model
validation and compatib
On Fri, Aug 16, 2013 at 7:45 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> 8. I've added a new check. If you're using a `GenericRelation` but there
>> is no
>> `GenericForeignKey` on the target model, an warning is raised. This check
>> was
>> implemented in this commit [9]. It use
Hi Christopher,
On Wed, Aug 14, 2013 at 11:26 PM, Christopher Medrela <
chris.medr...@gmail.com> wrote:
> *Progress.*
>
> - Deprecated `requires_model_validation` flag and `validate` method (both
> `BaseCommand` members) in favour of new `requires_system_checks` flag and
> `check` method.
>
>
*Progress.*
- Deprecated `requires_model_validation` flag and `validate` method (both
`BaseCommand` members) in favour of new `requires_system_checks` flag and
`check` method.
- Finished working at `contenttypes` tests.
- Improved code thanks to Preston Holmes comments. Deleted dead code and
On Wed, Aug 7, 2013 at 4:03 AM, Christopher Medrela wrote:
> I'm still working at polishing after reviewing. I've deprecated
> `requires_model_validation` and `validate`. I've started at adding tests
> for
> contenttype fields: `GenericForeignKey` and `GenericRelation`.
>
> I've updated gsoc2013-
I'm still working at polishing after reviewing. I've deprecated
`requires_model_validation` and `validate`. I've started at adding tests for
contenttype fields: `GenericForeignKey` and `GenericRelation`.
I've updated gsoc2013-checks-review branch [1]. Now it's the same as
gsoc2013-checks branch [2
Unfortunately, I'm a bit late. I didn't suspected that polishing code after
review takes so much time. Lots of my work from last Wednesday was small
improvements, but there are some vital changes:
The API will be consistent with API of logging module or message framework.
Being consistent means th
On Thursday 25 July 2013 08:37:06 Russell Keith-Magee wrote:
>
> Could I get you to open this as a ticket so that it isn't forgotten?
>
https://code.djangoproject.com/ticket/20814
Thanks,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django develo
Hi Shai,
Could I get you to open this as a ticket so that it isn't forgotten?
Russ %-)
On Thu, Jul 25, 2013 at 8:12 AM, Shai Berger wrote:
> Hi Christopher,
>
> While you're dealing with model validation, I wonder if you can take a
> look at
> this little example -- a minor failure in the curr
Hi Christopher,
While you're dealing with model validation, I wonder if you can take a look at
this little example -- a minor failure in the current model validation:
class General(models.Model):
name = models.CharField(max_length=30)
class Special(General):
pass
cl
On Wed, Jul 24, 2013 at 4:17 AM, Christopher Medrela <
chris.medr...@gmail.com> wrote:
> Progress: I've implemented registering entry points. Now there is
> `django.core.checks.register(callable)` function. There is no
> `run_in_development` and `run_in_production` arguments. I've also rewritten
>
Progress: I've implemented registering entry points. Now there is
`django.core.checks.register(callable)` function. There is no
`run_in_development` and `run_in_production` arguments. I've also rewritten
mechanism of triggering checking framework -- `BaseCommand.validate` calls
`django.core.checks.
I've created a pull request [1] to make deep review easier. I've rolled out
tests we were talking about and reverted `validate_field` -- there exist
both `check_field` and `validate_field`, the first calling the second.
[1] https://github.com/django/django/pull/1364
--
You received this messag
On Mon, Jul 15, 2013 at 8:17 PM, Christopher Medrela <
chris.medr...@gmail.com> wrote:
> Progress: I've implemented manager checks.
>
> The schedule for the next 4 weeks is:
>
> 1. Manager checks (ref 4.1.7)(done)(0.5 week).
> 2. Entry point registering (ref 4.1.5) & rewriting mechanism of trigger
Hi Chris,
On Fri, Jul 12, 2013 at 7:45 PM, Christopher Medrela <
chris.medr...@gmail.com> wrote:
> Finally, I've rewritten all model and field tests and checks. Some new
> tests
> were written. First draft of checking framework documentation was written.
> All
> tests passes (at least at my compu
Progress: I've implemented manager checks.
The schedule for the next 4 weeks is:
1. Manager checks (ref 4.1.7)(done)(0.5 week).
2. Entry point registering (ref 4.1.5) & rewriting mechanism of triggering
checking framework (ref 4.1.9)(1.5 week).
3. Moving custom User model checks (ref 4.1.6)(0.
Finally, I've rewritten all model and field tests and checks. Some new tests
were written. First draft of checking framework documentation was written.
All
tests passes (at least at my computer). I've rebased my branch
(`gsoc2013-checks` [1]) against master. The branch is ready to deep review.
[1
I'm finishing making field tests green. I'm a bit late, because the schedule
says that I should finish this job by the end of the previous week. My
excuse is
that I had exams in the previous week so I couldn't focus on GSoC.
Fortunately,
I passed all exams and now I can work full time on GSoC and
Hello!
I've deleted old `gsoc2013-verification` branch. Follow the new
`gsoc2013-checks` branch [1].
[1] https://github.com/chrismedrela/django/tree/gsoc2013-checks
What did I do? I've rewritten field tests living in
`django.tests.invalid_models` package [2], inside `tests.py` file [3]. I've
ren
Hi Chris,
On Tue, Jun 11, 2013 at 4:29 PM, Christopher Medrela <
chris.medr...@gmail.com> wrote:
> 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
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 t
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
Hello!
I'm really happy that I've been accepted as a Google Summer of Code
student. I
will work at revamping validation framework and merging django-secure this
summer. I created this thread to start discussion (especially about public
API) and get some feedback as well as to share progress. Any
38 matches
Mail list logo
