I'd like to argue in favor of exercising caution when using CBVs.
In my experience, CBVs shine when the requirements closely match the use
case for a certain CBV and all customizations are purely declarative, often
just setting the model. With the level of expressiveness that Python gives
us a
I'm +1 with Baptiste, Ben, Josh and João.
Also, Luke, you said :
> 1. Recognise that CBVs are much harder to reason about, and therefore
> require much more care.
2. Avoid using CBVs unless you really need them.
>
Just wanted to note that this means never. FBV vs CBV is a choice, there's
re
Hi all,
First, I want to say that complex things fail in complex ways, so there
it's probably a fallacy to look for a single root cause. I agree with
various other points about mistakes that were made, but not others.
Particularly:
On 22/11/16 12:41, Florian Apolloner wrote:
Hi,
On Monday,
+1 to Baptiste, Ben and Josh. Especially as Ben said, I think this does not
justify removing the auth CBVs. The bug happened because of a *misuse* of
the abstractions involved. ``.get_context_data()`` is not the correct place
for a security check (as nobody overriding it would expect that, nor from
+1 to everything Baptiste and Ben have said. A bug in a CBV isn't a good
argument for throwing away CBVs entirely. We should probably review patches
that touch security systems quite a bit more thoroughly in the future -
meaning more eyes rather than a single set of eyes spending more time.
On
As a big fan of GCBVs, this got me out of the chair :) I am -1 for removing
GCBVs for authentication.
My reasons:
1) Security improvements also happen over time, finding a security hole in
a component is not a reason to point the finger at the architecture. If you
entirely remove something, yo
Hello,
Thank you for raising this, Markus.
I am +1 to everything Baptiste said.
In particular, if our conclusion of this bug would be that CBV are entirely
unsuitable for security sensitive features, I don’t think removing CBV for auth
is enough. Because by that logic, our users will be making
Hi,
On Monday, November 21, 2016 at 11:56:56 PM UTC+1, Tim Graham wrote:
>
> … that the existing tests would catch this type of obviously incorrect
> issue.
>
I think that is the main issue here. I was also really surprised to
discover that the tests were missing cases like this -- then again,
Hi Markus,
Thanks for your clear description and for bringing this up for discussion.
I don't agree with your conclusions though.
1) Keeping around two implementations of auth views seems
counter-productive to me in terms of security because it effectively
doubles the potential for bugs or s
Le lundi 21 novembre 2016 23:56:56 UTC+1, Tim Graham a écrit :
>
> When reviewing the patch for the auth class-based view additions, I made
> the mistake of assuming that the existing tests would catch this type of
> obviously incorrect issue. Perhaps with the function-based views, the code
> wa
> I think that patch was just an example of bad abstraction. For instance,
_log_and_response was strange and confusingly named, and seemed to be there
mostly for vanity, to mask the imperative nature of the top level of
control.
Proposed patch author here. Yes, I agree that wasn't a very successfu
> I found it much more difficult to follow to the point where I didn't feel it
> was an improvement.
I think that patch was just an example of bad abstraction. For instance,
_log_and_response was strange and confusingly named, and seemed to be there
mostly for vanity, to mask the imperative nat
I haven't extended these views much, so I can't talk about the pain points
of extending the function-based views compared to the ease of extending the
classes. I'm certainly more confident about reasoning with function-based
code. There was a draft patch [0] a few months ago that converted some
Just to be absolutely clear, in case it's needed...
> is to hold off the deprecation of the function-based views.
Markus is specifically referring to the FBV implementations of the
contrib.auth views here.
(Not to FBVs generally, which we've no intention of deprecating whatsoever)
- Tom
>
-
Hi all,
As it turned out [1], due to their complexity, using class-based generic
views for security-sensitive functionality can result in unintended
behavior. Essentially, the reset token was only checked on GET requests,
not on POST. This was due to the check being in `get_context_data()` (whi
15 matches
Mail list logo
