Code

Opened 3 years ago

Closed 3 years ago

#15891 closed Bug (wontfix)

flushing session on auth.logout

Reported by: sorl Owned by: nobody
Component: contrib.auth Version: 1.3
Severity: Normal Keywords:
Cc: mikko@…, florian@…, mathieu.agopian@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX:

Description

Flushing the session on logout or logging in with another user before logging the other user out will empty the session for all other applications using session data obviously. Should "Logout" in the admin really mean "completely erase all my session data for this site."? What if other applications acted this way, flushing the session data whenever it did not need it anymore.

Attachments (1)

session.patch (1.3 KB) - added by sorl 3 years ago.

Download all attachments as: .zip

Change History (11)

Changed 3 years ago by sorl

comment:1 Changed 3 years ago by Mathieu Agopian <mathieu.agopian@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Hello sorl,

I thought i could just add a specific use case that could possibly problematic, for further discussion.

When user A logs in, a warning message is displayed about some upcoming website maintenance. Once the user acknowledges this message, it stores SESSION['msg_read'] = True.

When user B logs in, if SESSION['msg_read'] isn't flushed, the warning message won't display.

I know the msg_read key could be flushed manually by registering to the user_logged_in or user_logged_out signals, i'm just not sure the responsability should be given to the developer in cases where there's potentially private/sensitive data that could leak from a user to another.

What about a way to specify in the settings if we specifically don't want to flush the whole session, but just the SESSION_KEY and BACKEND_SESSION_KEY ?
This way, by default, the current (safe) implementation would be used.

Set this ticket as "design decision needed" ?

comment:2 follow-up: Changed 3 years ago by sorl

@Mathieu Agopian
I can't make any sence from that use case, session data is not a global object and does not leak unless you hijack the other users session id.

comment:3 in reply to: ↑ 2 Changed 3 years ago by anonymous

Replying to sorl:

@Mathieu Agopian
I can't make any sence from that use case, session data is not a global object and does not leak unless you hijack the other users session id.

Yes it does leak, think of computers where more than one user uses the same browsersession (Those still exists, especially @home if the users share the same username etc…)

comment:4 Changed 3 years ago by apollo13

  • Cc florian@… added

comment:5 follow-up: Changed 3 years ago by sorl

I am confused, we should support users sharing session ids?

comment:6 Changed 3 years ago by magopian

  • Cc mathieu.agopian@… added

comment:7 in reply to: ↑ 5 Changed 3 years ago by apollo13

Replying to sorl:

I am confused, we should support users sharing session ids?

Not necessarily, but it can happen; Better be safe than sorry. (Eg for instance, I do use a "trusted" friend's laptop if I forget mine to check something; of course I use his browser then…).

comment:8 Changed 3 years ago by sorl

So this means the auth app should take care of cleaning session data for all other applications on logging out whether they like it or not. That can't be right?

comment:9 Changed 3 years ago by apollo13

  • Triage Stage changed from Unreviewed to Design decision needed

Putting into DDN, although it should be wontfix imo.

comment:10 Changed 3 years ago by SmileyChris

  • Resolution set to wontfix
  • Status changed from new to closed

It's tight coupling between auth and session, but it's by design. I'm going to close this - but if you feel strongly sorl then bring it up on django-dev.

(the slightly wonky side discussion of 'what if the session is used in multiple places' did nothing to sway me in this direction)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.