On Sat, 18 Aug 2018 21:27:02 +0200
Adam Johnson wrote:
> I'm not sure introducing this change because one analyzer tool
> currently picks up on the signal is a great reason, only a little bit
> of potential obscurity is gained. Especially since it's a problem for
> big sites deploying it, as
I've thought about this a bit, especially back in the context of tracking
how many sites use Django. Besides the CSRF token input name there are
probably tens to hundreds of little signals that a site runs Django, e.g.
the presence of /admin/, CSRF/session cookie presence/size, APPEND_SLASH,
Hello,
I'd be in favor of what's proposed.
Slightly related, this made me remember I had some note about proposing we
add either to the Security or the Deployment checklist documents
suggestions about (also) customizing the CSRF_COOKIE_NAME,
LANGUAGE_COOKIE_NAME and SESSION_COOKIE_NAME settings.
Hello,
Perhaps we could reuse settings.CSRF_COOKIE_NAME there instead of the hardcoded
"csrfmiddlewaretoken"? That would meet the stated goal without introducing a
new setting. Also it feels sensible to me to use the same name for the input
and the cookie.
There would be some hiccups — 403
Do you think it's worth a new setting to allow customizing the CSRF token
name ('csrfmiddlewaretoken')?
It was proposed 9 years ago in https://code.djangoproject.com/ticket/12738
and closed as wontfix absent some justification.
It was again proposed a few days ago in
