Opened 4 years ago

Closed 4 years ago

#24511 closed Uncategorized (wontfix)

New feature: Make the session cookie secure if and only if request.is_secure()

Reported by: Antonis Christofides Owned by: nobody
Component: Uncategorized Version: 1.7
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Usually I require logged on users to use https. In that case, I specify SESSION_COOKIE_SECURE = True. This, however, makes it impossible to use anonymous sessions over http.

Examples: I have used sessions to store the sort order of a table, and to store the user's preferred language (I know language is also a browser setting, but sometimes it's not enough). These need to be available in anonymous sessions as well.

Sometimes what I do is run two instances of Django, with different; one has SESSION_COOKIE_SECURE = True, the other False; and I configure the web server to use the first one for https and the other one for http. But I think this is overkill when Django could simply look at request.is_secure() and decide accordingly.

I may write a patch about that, but first I wanted to know whether I'm understanding something wrong.

Change History (2)

comment:1 Changed 4 years ago by Sasha Romijn

Although seemingly logical, I think this is not a good plan. I can think of several issues where the logic would get very complex, but most of all, I don't think Django should introduce implicit behaviour to benefit mixed security sites. Mixed security sites are awful, security wise, and Django should not encourage such setups. A minor flaw in the logic of when cookies should be secure can severely compromise the security of a site. And even if the session cookie is 100% safe, a mixed security site offers opportunities for active interception to prevent redirects to https, or change the URL behind the login button, etc.

The resolution to your problem is to simply run your entire site over https.

I'm closing this as wontfix -

comment:2 Changed 4 years ago by Sasha Romijn

Resolution: wontfix
Status: newclosed

Apologies, clicked submit too early: I'm closing this as wontfix, if you still feel we should change this then the best place for discussion would be the DevelopersMailingList.

Note: See TracTickets for help on using tickets.
Back to Top