[Django] #23957: Start a deprecation path toward requiring session verification
Django
------------------------------------------------+------------------------
Reporter: timgraham | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: contrib.auth | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
From Carl in comments of #23939: "Is there a use case for a long-term
simple way to disable this behavior? Or is it just a way to preserve
sessions across the upgrade that we need? I think we should be on a
deprecation path to making [session verification] always-on; I think it's
fine if you have to write your own `AuthenticationMiddleware` if you don't
want it."
As far as I know, the only-use case for disabling it was to provide an
upgrade path.
The deprecation path could look like this:
1.8: Raise `RemovedInDjango20Warning` if `AuthenticationMiddleware` but
not `SessionAuthenticationMiddleware` is in `MIDDLEWARE_CLASSES` (because
session verification will be mandatory in 2.0)
2.0: It's now safe to remove `SessionAuthenticationMiddleware` from
`MIDDLEWARE_CLASSES` since the behavior can't be turned off. Raise
`RemovedInDjango22Warning` if it's there so we can eventually remove the
class.
--
Ticket URL: <https://code.djangoproject.com/ticket/23957>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: timgraham | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: contrib.auth | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by carljm):
I considered this version of the deprecation path (without ever
introducing an `AUTH_VERIFY_SESSION` setting). But I don't like it,
because it involves raising one deprecation warning for two versions
telling people to add something to their settings, and then raising
another deprecation warning the following version telling them they should
remove the thing they just added.
So even though it involves a new setting, I still think it's better to add
`AUTH_VERIFY_SESSION` in 1.8 when we deprecate
`SessionAuthenticationMiddleware`, so that people can immediately add
`AUTH_VERIFY_SESSION = True`, remove `SessionAuthenticationMiddleware`,
and never again see another deprecation warning related to this feature.
(In 2.0 their `AUTH_VERIFY_SESSION = True` will become unnecessary, but it
still won't be deprecated).
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:1>
Django
Reporter: timgraham | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: contrib.auth | Resolution:
Severity: Normal | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I'd take another angle and say I'd prefer Django to tell me when I have a
useless setting around so I can keep things clean. Am I underestimating
the difficulty of adding/removing one line from `settings.py`? I think
that's less of a burden than the cognitive load of a new setting. It seems
cleaner to have one way to activate session verification. Alternatively,
I'd opt to keep `SessionAuthenticationMiddleware` around indefinitely (as
a no-op) if you think deprecating it immediately at 2.0 will cause pain.
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:2>
Django
Reporter: timgraham | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: contrib.auth | Resolution:
Severity: Normal | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by carljm):
I think there's a cumulative burden to deprecation warnings period,
somewhat independently of how hard or easy they are to address; as they
accumulate, they increase the sense that migrating from one Django version
to the next is a chore.
Mostly, I was hoping we could confine the "check for a no-op middleware in
MIDDLEWARE_CLASSES" hack to those projects created on 1.7, and deprecate
it right away on 1.8, rather than forcing everyone to use it, and keeping
it around until 2.2 or later. But I agree with you that adding a new
setting that we plan to immediately deprecate is sad, too. So I'm OK with
either approach.
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:3>
Django
Reporter: timgraham | Owner: timgraham
Type: | Status: assigned
Cleanup/optimization | Version: master
Component: contrib.auth | Resolution:
Keywords: | Needs documentation: 0
Has patch: 0 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by timgraham):
* owner: nobody => timgraham
* status: new => assigned
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:4>
Django
Reporter: timgraham | Owner: timgraham
Type: | Status: assigned
Cleanup/optimization | Version: master
Component: contrib.auth | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by timgraham):
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/3686 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:5>
Django
Reporter: timgraham | Owner: timgraham
Cleanup/optimization | Version: master
Component: contrib.auth | Resolution: fixed
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"b6ea059b4ab7a4ed7e84cad639df95fc9d61dd81"]:
{{{
#!CommitTicketReference repository=""
revision="b6ea059b4ab7a4ed7e84cad639df95fc9d61dd81"
Fixed #23957 -- Started deprecation toward requiring session verification.
Thanks Carl Meyer for review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:6>
Django
Reporter: timgraham | Owner: timgraham
Type: | Status: closed
Cleanup/optimization |
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"849037af36000d53b0b3b52f780ff475534e195b" 849037af]:
{{{
#!CommitTicketReference repository=""
revision="849037af36000d53b0b3b52f780ff475534e195b"
Refs #23957 -- Required session verification per deprecation timeline.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:7>
Django
Reporter: Tim Graham | Owner: Tim
Type: | Graham
Cleanup/optimization | Status: closed
Component: contrib.auth | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"401c5b2e42bf9134d9221f446765dd0777306f0b" 401c5b2]:
{{{
#!CommitTicketReference repository=""
revision="401c5b2e42bf9134d9221f446765dd0777306f0b"
Refs #23957 -- Removed the useless SessionAuthenticationMiddleware.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23957#comment:8>