Re: ValidationError for fields

[Anssi Kääriäinen]

On 08/20/2013 08:26 AM, Loic Bistuer wrote:

An alternate would be to implement a method that does this.

def field_error(self, name, error):
 self._errors = self._errors or ErrorDict()
 self._errors.setdefault(name, ErrorList())
 self._errors[name].append(error)

I also have a pending PR for that: https://code.djangoproject.com/ticket/5335.

So you could do `self._errors[name].append(error)` from within the form and 
`self.errors[name].append(error)` from outside.


Having to raise a ValidationError would prevent you from creating multiple 
field errors from within `clean`.


Not necessarily, the `ValidationError` constructor accepts a variety of 
scenarios:

def clean(self):
 errors = {}
 if condition1:
 errors['field1'] = ValidationError('message1', code='code1')
 if condition2:
 errors['field2'] = ValidationError('message2', code='code2')
 raise ValidationError(errors)

Note that in the example above,  `ValidationError('message1', code='code1')` 
can also be a simple string, but if https://github.com/django/django/pull/1483 
(yet another PR) goes in, passing an error code will become quite useful.

I really like the Form.add_error(field, error_message) approach. I have 
used it as custom addition in some of my projects, and it just feels 
correct.


 - Anssi

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

[Loic Bistuer]

> An alternate would be to implement a method that does this.
> 
> def field_error(self, name, error):
> self._errors = self._errors or ErrorDict()
> self._errors.setdefault(name, ErrorList())
> self._errors[name].append(error)

I also have a pending PR for that: https://code.djangoproject.com/ticket/5335.

So you could do `self._errors[name].append(error)` from within the form and 
`self.errors[name].append(error)` from outside.

> Having to raise a ValidationError would prevent you from creating multiple 
> field errors from within `clean`. 


Not necessarily, the `ValidationError` constructor accepts a variety of 
scenarios:

def clean(self):
errors = {}
if condition1:
errors['field1'] = ValidationError('message1', code='code1')
if condition2:
errors['field2'] = ValidationError('message2', code='code2')
raise ValidationError(errors)

Note that in the example above,  `ValidationError('message1', code='code1')` 
can also be a simple string, but if https://github.com/django/django/pull/1483 
(yet another PR) goes in, passing an error code will become quite useful.

-- 
Loic

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

[Aaron Merriam]

+1 on a better way to do field errors.

An alternate would be to implement a method that does this.

def field_error(self, name, error):
> self._errors = self._errors or ErrorDict()
> self._errors.setdefault(name, ErrorList())
> self._errors[name].append(error)


Having to raise a ValidationError would prevent you from creating multiple 
field errors from within `clean`. 

On Monday, August 19, 2013 6:58:25 PM UTC-6, Simon Litchfield wrote:
>
> Lack of clean control over field-specific form errors is an issue that has 
> been raised and discussed many times over the years, but still the solution 
> seems pretty inadequate. We're even directing people hack around with 
> _errors and making excuses for it in the documentation.
>
> https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors
>
> What about an optional kwarg on ValidationError? Eg, raise 
> forms.ValidationError('This field is seriously not cool', field='myfield'). 
> Current 
> behaviour as-is.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

[Loic Bistuer]

There is a ticket with a PR to address the issue of targeting specific fields 
when raising errors; I'm awaiting feedback on what should be the documented API.

https://code.djangoproject.com/ticket/20867.

This patch enables two patterns:

- Raising ValidationError({'field': 'error'}) from `Form.clean()`.

- Calling Form.add_errors('field', 'error') from anywhere.

The former is actually something that existed for a long time; only it couldn't 
be used from `Form.clean()`. This pattern allows targeting specific fields from 
the `Model` layer (see #16986).

The later has been proposed by @akaariai and @mjtamlyn, it's easier to use for 
the simple cases and it's accessible from outside the form, from a view for 
example.

The current patch only documents the dict construct for `ValidationError` since 
`Form.add_errors` was a private method in my original patch; should both be 
documented or only `Form.add_errors`?

-- 
Loic

On Aug 20, 2013, at 7:58 AM, Simon Litchfield  wrote:

> Lack of clean control over field-specific form errors is an issue that has 
> been raised and discussed many times over the years, but still the solution 
> seems pretty inadequate. We're even directing people hack around with _errors 
> and making excuses for it in the documentation.
> https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

ValidationError for fields

[Simon Litchfield]

Lack of clean control over field-specific form errors is an issue that has 
been raised and discussed many times over the years, but still the solution 
seems pretty inadequate. We're even directing people hack around with 
_errors and making excuses for it in the documentation.
https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors

What about an optional kwarg on ValidationError? Eg, raise 
forms.ValidationError('This field is seriously not cool', field='myfield'). 
Current 
behaviour as-is.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[Tim Graham]

Sounds good, Paul. Starting small is a good way to get started.

On Monday, August 19, 2013 5:06:46 PM UTC-4, Paul C. Anagnostopoulos wrote:
>
> Thanks, Daniele. That looks like good reading. 
>
> I'm making changes to templates/builtins.txt. I can make the html files 
> and preview my changes in my browser. Seems to me it would make sense to 
> contribute just a few changes as a test of submission procedures. Is that a 
> good idea?
>
> ~~ Paul
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Usage and documentation of F()

[Curtis Maloney]

Just a simple case of what I was talking about earlier, here's something we
used to avoid having to pass datetime.datetime.now() to a lot of timestamp
filtering queries:

class Now(ExpressionNode):
def __init__(self):
super(Now, self).__init__(None, None, False)

def evaluate(self, evaluator, qn, connection):
return 'CURRENT_TIMESTAMP', []

A little research shows this should work [almost] identically on all the
majors, and even Oracle and MS SQL.  The "almost" is become some will shift
the timestamp during a transaction, and others won't.

Now, how many other handy "SQL Standard" functions/expressions are there
that people would love to use?

--
Curtis


On 20 August 2013 02:40, Andre Terra  wrote:

>
> On Sat, Aug 17, 2013 at 10:22 PM, Curtis Maloney <
> cur...@acommoncreative.com> wrote:
>
>> If, at the same time, perhaps ExpressionNode got a mention too, that
>> could really open up some opportunities :)
>
>
> Speaking of opportunities, here's a worthwhile ticket if we want to go
> further than docs for improving F():
>
> https://code.djangoproject.com/ticket/14030
>
>
> Cheers,
> AT
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[Paul C. Anagnostopoulos]

Thanks, Daniele. That looks like good reading. 

I'm making changes to templates/builtins.txt. I can make the html files and 
preview my changes in my browser. Seems to me it would make sense to 
contribute just a few changes as a test of submission procedures. Is that a 
good idea?

~~ Paul

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[Daniele Procida]

On Mon, Aug 19, 2013, Paul C. Anagnostopoulos  wrote:

>I'd like to contribute to Django by improving the "Built-in template tags 
>and filters" document. I forked the Django repository at GitHub. Then I 
>tried to clone it according to the instructions in "Working with Git and 
>GitHub." I received:

It sounds like you've resolved the issue you had, but you might find the 
Git/Github pages at 

 useful - they are the result of my having struggled through just the kind of 
problems you described.

Daniele

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: A diagram showing Class Based View inheritance and mixins.

[Seth Moon]

Such as one for each of the pink CBVs (CreateView, UpdateView, etc)? Yeah, 
I'll see what I can do.

On Monday, August 19, 2013 12:54:29 AM UTC-7, Daniel Greenfeld wrote:
>
> Seth,
>
> I like it a lot. Is there any chance you can provide a focused version per 
> Class-Based View?
>
> Daniel Greenfeld
>
> On Sunday, August 18, 2013 10:03:59 PM UTC+2, Seth Moon wrote:
>>
>> I believe it would be beneficial to the Django developers and users if 
>> the documentation included a diagram showing the complete structure of how 
>> Class Based Views get their functionality. This would be a relatively 
>> simple diagram that shows the classes each generic view inherits from. The 
>> reason I am proposing this is because the current state of Generic Class 
>> Based Views is too complex for many people, myself included, with some 
>> views inheriting from 9 other classes (CreateView, UpdateView) down a long 
>> chain of both single and multiple inheritance. This would also enable 
>> people to gain a deeper understanding of why the Views are structured the 
>> way they are, and encourage people to explore the available BaseViews and 
>> mixins in order to assemble more customized applications without having to 
>> reinvent the wheel.
>>
>> I posted this on the Django Reddit 
>> communitywith
>>  relative success being the top post. There is a 
>> DIA  diagram file and SVG available on 
>> a Google Drive 
>> folderthat
>>  is publicly accessible for you to download and modify. Version 3 is 
>> the most current revision and differs extensively from what I originally 
>> posted on Reddit.
>>
>> A preview of the diagram can be seen below (It's a fairly large image):
>>
>>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[Paul C. Anagnostopoulos]

That appears to have done the trick. Thanks!

~~ Paul

 

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[James Pic]

GitHub has great http support now, which includes pushes. I think the
documentation could mention https git urls everywhere:

- let users who know about the benefits of ssh keys use them on their own,
- let the others send their GitHub username/password at every push.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: New contributor and Git

[Flavia Missi]

Hi,

It seems you don't have your public key on github. Try to set your upstream
url with the read-only url with the following command:

$ git remote set-url upstream git://github.com/django/django.git

Hope it helps.


On Mon, Aug 19, 2013 at 3:24 PM, Paul C. Anagnostopoulos
wrote:

> Folks,
>
> I'd like to contribute to Django by improving the "Built-in template tags
> and filters" document. I forked the Django repository at GitHub. Then I
> tried to clone it according to the instructions in "Working with Git and
> GitHub." I received:
>
> The authenticity of host 'github.com (204.232.175.90)' can't be
> established.
>
> So instead I cloned it according to the instructions in "Writing
> Documentation," which seemed to work. It specifies the following command:
>
> git clone git://github.com/Paul-C-Anagnostopoulos/django.git django-trunk
>
> Then I set up the upstream remote with:
>
> git remote add upstream g...@github.com:django/django.git
>
> Not sure why that didn't have an authenticity problem. Then:
>
> git fetch upstream
>
> which produced:
>
> Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> I'm not a clever Git user, so I could use some help in figuring this out.
> I'll check back here or you can contact me via email. I appreciate any
> assistance.
>
> ~~ Paul
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Flavia

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

New contributor and Git

[Paul C. Anagnostopoulos]

Folks,

I'd like to contribute to Django by improving the "Built-in template tags 
and filters" document. I forked the Django repository at GitHub. Then I 
tried to clone it according to the instructions in "Working with Git and 
GitHub." I received:

The authenticity of host 'github.com (204.232.175.90)' can't be established.

So instead I cloned it according to the instructions in "Writing 
Documentation," which seemed to work. It specifies the following command:

git clone git://github.com/Paul-C-Anagnostopoulos/django.git django-trunk

Then I set up the upstream remote with:

git remote add upstream g...@github.com:django/django.git

Not sure why that didn't have an authenticity problem. Then:

git fetch upstream

which produced:

Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I'm not a clever Git user, so I could use some help in figuring this out. 
I'll check back here or you can contact me via email. I appreciate any 
assistance.

~~ Paul

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

feedback needed: session serialization API (1.6 release blocker)

[Tim Graham]

Please take a look at the proposed session serialization API on ticket 
#20922  and add your thoughts 
if you have an interest in it.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Usage and documentation of F()

[Andre Terra]

On Sat, Aug 17, 2013 at 10:22 PM, Curtis Maloney  wrote:

> If, at the same time, perhaps ExpressionNode got a mention too, that could
> really open up some opportunities :)


Speaking of opportunities, here's a worthwhile ticket if we want to go
further than docs for improving F():

https://code.djangoproject.com/ticket/14030


Cheers,
AT

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #19316 broke the external API of django.views.generic.View by changing where self.request is set

[Marc Tamlyn]

Using views externally to `.as_view()` sounds like a potential pitfall to
me - I would not suggest that this is part of the public API of a view. Is
this in testing code, or production?

As for the change itself, this was precisely done *because* we want people
to override `dispatch()` - the issue was that I could not override dispatch
and then call, say, `get_object()` without duplicating some lines from
`dispatch()`.

I agree that the API has changed slightly, and it's now much closer to its
actual purpose - choose which method handler to call and call it. It also
acts as a hook for method-independent code.

Also, as that change has been released in 1.5.X for several months, it's
likely to late to back out of it without really good reason.

I hope that makes sense?


On 19 August 2013 14:52, Jonas Maurus  wrote:

> Hey everyone,
>
> #19316, or more specifically
> https://code.djangoproject.com/changeset/12cf9d2be3cccb2ff63d78e93f97188040488a3dseems
>  to have broken the documented API of View.
>
> In
> https://docs.djangoproject.com/en/dev/ref/class-based-views/base/#django.views.generic.base.View.dispatch,
> dispatch() seems to be part of the external API of View. We happen to call
> dispatch() directly on View subclass instances in django-flows (
> https://github.com/laterpay/django-flows, specifically
> https://github.com/laterpay/django-flows/blob/develop/flows/handler.py#L413).
> Due to the change set above, calling dispatch() on FormView subclasses will
> now always fail as FormView expects self.request to be set, but that will
> only happen in the closure returned by as_view().
>
> I think that the change in #19316 should be backed out or alternatively
> dispatch() should be removed from the public API as _dispatch, at which
> point the constructor to View() should also be made private. Right now
> however, people are encouraged to override dispatch() in subclasses, so I
> think the change is just broken.
>
> To summarize: Unless I missed something, it seems to me that dispatch
> can't be reliably called from the outside without setting up the instances
> .request, .args and .kwargs attributes.
>
> I hope somebody here can take a look and tell me if I'm way off course or
> whether this is a legitimate bug :).
>
> Thanks and best regards,
> Jonas
>
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

#19316 broke the external API of django.views.generic.View by changing where self.request is set

[Jonas Maurus]

Hey everyone,

#19316, or more 
specifically 
https://code.djangoproject.com/changeset/12cf9d2be3cccb2ff63d78e93f97188040488a3d
 
seems to have broken the documented API of View. 

In 
https://docs.djangoproject.com/en/dev/ref/class-based-views/base/#django.views.generic.base.View.dispatch,
 
dispatch() seems to be part of the external API of View. We happen to call 
dispatch() directly on View subclass instances in django-flows 
(https://github.com/laterpay/django-flows, specifically 
https://github.com/laterpay/django-flows/blob/develop/flows/handler.py#L413). 
Due to the change set above, calling dispatch() on FormView subclasses will 
now always fail as FormView expects self.request to be set, but that will 
only happen in the closure returned by as_view().

I think that the change in #19316 should be backed out or alternatively 
dispatch() should be removed from the public API as _dispatch, at which 
point the constructor to View() should also be made private. Right now 
however, people are encouraged to override dispatch() in subclasses, so I 
think the change is just broken.

To summarize: Unless I missed something, it seems to me that dispatch can't 
be reliably called from the outside without setting up the instances 
.request, .args and .kwargs attributes.

I hope somebody here can take a look and tell me if I'm way off course or 
whether this is a legitimate bug :).

Thanks and best regards,
Jonas


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: CSRF protection question

[James Roper]

Thanks very much for your reply, knowing the reasoning behind the decisions
made really helps.

Cheers,

James


On 17 August 2013 11:56, Russell Keith-Magee wrote:

>
> On Thu, Aug 15, 2013 at 7:21 PM, James Roper  wrote:
>
>> Hi,
>>
>> I'm a core dev on Play Framework, and I'm currently looking closely at
>> our CSRF protection and making improvements, and so I'm looking carefully
>> at what other frameworks do because when it comes to security, it's easy to
>> miss something.
>>
>> I'd like to get a better understanding of the reason behind why
>> X-Requested-With is no longer supported in Django.  I've read about the
>> vulnerability behind it:
>>
>> https://blog.whitehatsec.com/flash-307-redirect-game-over/
>>
>> What I don't understand is why this vulnerability required server side
>> fixes.  It's clearly a client side vulnerability, here's the Firefox
>> version of the vulnerability in the NVD:
>>
>> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0059
>>
>> It is clearly stated that the vulnerability is in Firefox, not on the
>> server side.  Firefox has since fixed the issue.  The issue is also fixed
>> in Chrome:
>>
>> https://code.google.com/p/chromium/issues/detail?id=63698
>>
>> So what I don't understand is why Django and Rails both raced to fix this
>> on the server side?  It makes it a pain in both frameworks to do AJAX
>> calls, where X-Request-With was such a simple solution.  And now that
>> clients are fixed, the server side fixes don't seem to be necessary
>> anymore.  Is there something I've missed?
>>
>> Yes. Firefox and Chrome have *subsequently* fixed the issue. But you have
> no control over user space, and you have absolutely no guarantee that *all*
> users are using fixed browsers. Users don't always update browsers when
> they're told to, even if you flash a "YOU ARE COMPROMISED! UPDATE!!1!"
> banner in front of them. There *were* compromised browsers in the wild, and
> we have no reason to believe that *every one of them* has been updated to
> remove the problem.
>
> I completely agree that the AJAX hole was very convenient. However, as a
> project, Django wasn't willing to allow *any* possibility of an exploit,
> now or in the future, so we had to remove the exception.
>
>
>> Also, was this ever really fixed in Django?  Rails stores the token in
>> the session, but Django stores the token in a cookie.  But since the
>> vulnerability allowed setting arbitrary headers, couldn't an attacker just
>> set the Cookie header to set the token to be whatever they wanted, and
>> submit a token in the form that matched?  I ask because Play has an option
>> that allows storing the token in a cookie, and I'd like to fully understand
>> what if any issues there are with that (I can see from the Django source
>> code that mitm attacks with SSL are a big pain to deal with for one).
>>
>
> I'll stand corrected on this, but the vulnerability wasn't about
> *completely* arbitrary headers -- it was just the extension headers. To the
> best of my knowledge, cookies are still safe -- they can't be set across
> domains, unless you have either a MITM attack vector, or a
> subdomain/wildcard cookie.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/75hNjzboNkM/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: tests failing/throwing errors - not sure where to start

[Russell Keith-Magee]

On Mon, Aug 19, 2013 at 4:13 PM, VernonCole  wrote:

> Kris:
>   9 failures and 17 errors are not an unusual number (out of 556 tests)
> given the complexity of django and the number of platforms it works on.
>  The number and selection of failed tests will vary depending on the exact
> implementation you are running. However, I notice that _none_ of the errors
> your are seeing are in core django -- all are in either django.contrib or
> another package.  Also -- you are not running a development (or indeed,
> even a current) version of django, so the errors you have seen have very
> possibly been fixed in the latest version(s).
>   Given that "The project I'm working on seems to work fine" I would say
> that there is no cause for concern.  If you wish to help test and/or debug
> django, you should do so using the latest version.
>

Wow… that's… a concerning opinion.

A test failure is a problem - period. There's no safe level of test
failures. Django's test suite should not have *any* failures in it. A
repeatable test failure in Django's suite is considered a release blocking
bug. If you're happy to live with "The app seems to work fine", why bother
having a test suite in the first place. The purpose of at test suite is to
draw your attention to the myriad ways that your app may *not* be fine.

It's difficult to establish exactly what has caused these errors without
seeing all the code, but the errors you're getting point to something
fairly fundamental going wrong. Failures caused by tables not being created
are a fairly fundamental failure. The way your UserCreationForm is failing
is also suspicious.

Two possibilities that spring to mind:

 * You don't *actually* have Django 1.4.3 -- you may have a corrupted half
install of two different versions (possibly by installing one version over
another in an unusual way)

 * There's something in the rest of your stack that is messing with
Django's internals.

The first step -- try to run Django's own test suite. This should pass
without any errors.

Second step -- run the test suite on a clean project (i.e., no extra apps
installed). This should also pass without errors.

Then, you can progressively start introducing new components until you
either have a full app with a fully passing test suite, or you can identify
the component that is causing problems.

Yours,
Russ Magee %-)

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Proposal: Deprecate SimpleTestCase.settings and SimpleTestCase.urls

[Krzysztof Jurewicz]

There is a SimpleTestCase.settings method added in commit 0dc6420ⁱ, 
which, according to the docstring, returns “A context manager that 
temporarily sets a setting and reverts back to the original value when 
exiting the context.”. In commit a3a53e0² its implementation has been 
simplified so that now it is only an identity wrapper around 
override_settings class (which was added in the same commit). The 
documentation states that SimpleTestCase.settings should be used as a 
context manager and override_settings should be used as a decorator³, 
but, given that implementation, override_settings can be used for both 
tasks. Making a distinction generates only unnecessary noise, so I 
propose to deprecate and remove SimpleTestCase.settings method and 
document the fact that override_settings can act also as a context manager.


There is also a SimpleTestCase.urls class attribute which allows user to 
specify overriden ROOT_URLCONF setting. It was added in commit 415bd69⁴, 
long before SimpleTestCase.settings and override_settings were 
available. Currently the same effect can be achieved with 
override_settings decorator, so SimpleTestCase.urls can be considered 
redundant, and also marked for deprecation.


Krzysztof

ⁱ https://github.com/django/django/commit/0dc6420
² https://github.com/django/django/commit/a3a53e0
³ 
https://docs.djangoproject.com/en/dev/topics/testing/overview/#overriding-settings

⁴ https://github.com/django/django/commit/415bd69

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Performance optimisations in the deployment checklist document

[Marc Tamlyn]

Opened https://code.djangoproject.com/ticket/20938


On 16 August 2013 20:01, Daniele Procida  wrote:

> On Fri, Aug 16, 2013, Tim Graham  wrote:
>
> >I don't think there's a reason to recommend one of the two cached sessions
> >backends over the other as the choice is application dependent, but +1 on
> a
> >link to
> >https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cached-
> >sessions as
> >something to consider.
>
> There should presumably also be a similar pointer to this topic in the
> general optimisation and performance documentation described in <
> https://code.djangoproject.com/ticket/20877>.
>
> Daniele
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Model.__eq__

[Anssi Kääriäinen]

On Wednesday, August 7, 2013 10:45:01 AM UTC+3, Anssi Kääriäinen wrote:
>
> The way Model.__eq__ works currently should be improved. There is one 
> definite bug in __eq__, that is deferred instances aren't never equal to 
> non-deferred instances with same PK. There are also two possible 
> improvements: make proxy models equal to their concrete parents (this also 
> fixes deferred __eq__) and make multitable inherited models equal to their 
> parents.
>
> There are a couple of tickets about these issues: 
> https://code.djangoproject.com/ticket/11892, 
> https://code.djangoproject.com/ticket/16458 and 
> https://code.djangoproject.com/ticket/14492
>
> A patch for proxy equality is available at 
> https://github.com/akaariai/django/tree/model_eq_proxy and for model 
> inheritance equality at 
> https://github.com/akaariai/django/tree/model_eq_inherit.
>
> I think proxy equality is the right way to go. The reason is backwards 
> compatibility. A proxy model always represents the same data as its parent, 
> so change in proxy equality seems somewhat safe. This is not true for 
> multitable inheritance equality. For one breakage caused by inheritance 
> equality see the admin_views tests in model_eq_inherit branch. It seems 
> pretty much impossible to have a deprecation period for this change.
>
> So, I am planning to go forward with the model_eq_proxy branch. Any 
> comments or objections? Is even proxy equality too big of a change from 
> backwards compatibility perspective?
>

The model_eq_proxy branch just went in.

There are still two tickets that are related to Model.__eq__. These are 
#18250 and #18864. They both deal with instances which do not yet have any 
primary key value. Currently Django gives them hash value of hash(self.pk) 
== hash(None), and compares them as self.pk == other.pk, that is all pk == 
None instances are equal. This isn't helpful at all. The obvious choice is 
to make model.__eq__ use "self is other" in case of no primary key value 
(or equivalently id(self) == id(other)).

If __eq__ is based on id(), then __hash__ should be too. Unfortunately this 
leads to mutable hash value when an instance is saved. So, for __hash__ 
there seems to be at least three choices:
  1) Just don't care about mutable hash value problem. It is there already, 
in the form of hash(None) to hash(pk value). But the current situation 
isn't that bad as no-pk-value instance's aren't that useful in hash based 
containers (you can have only one instance without pk value in them).
  2) Prevent hashing of no pk value instances.
  3) Allow hashing of no pk value instances, but throw an error if the same 
instance is hashed both with and without primary key value.

I think option 2) is the way to go. While it can cause backwards 
compatibility problems, putting instances without primary key value into 
containers hasn't been that useful in previous Django versions. You could 
after all have just one instance without pk value in the container. It is 
extremely likely that any current use of no-pk-value instances in 
containers contains a bug or unwanted behaviour.

There is one backwards incompatibility for option 2) in Django. A test 
tries to validate an inline formset with a base instance that doesn't have 
a primary key value. While the test makes sense the overall situation 
doesn't - the formset does validate but saving it leads to exception. The 
validation code is trying to check unique_together conditions by putting 
the instance together with the other field's value into a set. This seems 
suspicious, as all instances without pk value hash to same bucket. I am 
unsure if the validation code actually contains a bug or not.

Option 1) will very likely lead to hard to solve bugs. Option 3) has the 
same problem but is isn't as bad. For example this will not work:

a = MyModel()
mydict[a] = 'foo'
a.save()
MyModel.objects.get(pk=a.pk) in mydict
> False

Alex Gaynor also gave support for approach 2) in 
https://code.djangoproject.com/ticket/18864#comment:7 a year ago.

A branch implementing id() based __eq__ and preventing __hash__ for no 
primary key value instances is available at 
https://github.com/akaariai/django/tree/model_eq_nopk.

 - Anssi

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: remove triage stage someday/maybe

[Marc Tamlyn]

I agree with what Russ and Tim said. -0


On 19 August 2013 02:36, Russell Keith-Magee wrote:

>
> On Sun, Aug 18, 2013 at 4:10 PM, Wim Feijen  wrote:
>
>> Hi,
>>
>> When triaging tickets I came across the triage stage Someday/Maybe. The
>> docs say I shouldn't use it. :) I think they are right.
>>
>> For me triaging tickets is all about making a decision. I make a choice
>> between either: "yes, good idea", or "no, we definitely don't want that".
>> Someday/maybe seems like not a good choice here, because it leaves things
>> in the uncertain.
>>
>> Therefore, I'd like to propose to remove this triage stage, like we did
>> with design decision needed.
>>
>> Currently, there are 47 tickets marked as someday/maybe. Looking over
>> them, it seems to me that:
>> 1. most can be marked as Accepted. A solution may or may not be hard to
>> find but we accept that django could improve here.
>> 2. some should actually be marked as won't fix but weren't out of
>> hospitality.
>>
>> What is your opinion?
>>
>
> I'm not sure I agree.
>
> DDN was being variously used as "accepted, but we need to work on the
> design" and "don't know if we want to accept this". This meant it ended up
> being an area where we punted on making hard decisions.
>
> However, "Someday/Maybe" are ideas that have been accepted, but are
> dependent on large pieces of work (like schema migrations or composite
> keys), or large backwards incompatibilities. If the dependencies land, or
> someone can work out a way around the backwards incompatibility problem,
> then they could move back to "accepted".
>
> Yes, we could just mark these all as "accepted". However, IMHO the
> "Someday/Maybe" marker provides a useful indicator to the community -- that
> this feature isn't going to land any time soon. Look at any long term
> accepted ticket, and there will be a "when will this be fixed in trunk"
> comment; "Someday/Maybe" gives a pre-emptive answer to this question.
>
> I'm -0 to removing Someday/Maybe.
>
> If there are tickets in Someday/Maybe that should be marked wont fix, or
> should be in accepted (because there's no architectural reason that they
> couldn't be implemented right now), please call them out -- it's entirely
> possible there are some tickets in there that need to be reassessed.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: tests failing/throwing errors - not sure where to start

[VernonCole]

Kris:
  9 failures and 17 errors are not an unusual number (out of 556 tests) 
given the complexity of django and the number of platforms it works on. 
 The number and selection of failed tests will vary depending on the exact 
implementation you are running. However, I notice that _none_ of the errors 
your are seeing are in core django -- all are in either django.contrib or 
another package.  Also -- you are not running a development (or indeed, 
even a current) version of django, so the errors you have seen have very 
possibly been fixed in the latest version(s).
  Given that "The project I'm working on seems to work fine" I would say 
that there is no cause for concern.  If you wish to help test and/or debug 
django, you should do so using the latest version.
--
Vernon

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: A diagram showing Class Based View inheritance and mixins.

[Daniel Greenfeld]

Seth,

I like it a lot. Is there any chance you can provide a focused version per 
Class-Based View?

Daniel Greenfeld

On Sunday, August 18, 2013 10:03:59 PM UTC+2, Seth Moon wrote:
>
> I believe it would be beneficial to the Django developers and users if the 
> documentation included a diagram showing the complete structure of how 
> Class Based Views get their functionality. This would be a relatively 
> simple diagram that shows the classes each generic view inherits from. The 
> reason I am proposing this is because the current state of Generic Class 
> Based Views is too complex for many people, myself included, with some 
> views inheriting from 9 other classes (CreateView, UpdateView) down a long 
> chain of both single and multiple inheritance. This would also enable 
> people to gain a deeper understanding of why the Views are structured the 
> way they are, and encourage people to explore the available BaseViews and 
> mixins in order to assemble more customized applications without having to 
> reinvent the wheel.
>
> I posted this on the Django Reddit 
> communitywith
>  relative success being the top post. There is a 
> DIA  diagram file and SVG available on a 
> Google 
> Drive 
> folderthat
>  is publicly accessible for you to download and modify. Version 3 is 
> the most current revision and differs extensively from what I originally 
> posted on Reddit.
>
> A preview of the diagram can be seen below (It's a fairly large image):
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.