[SECURITY BC BREAK] Do not reload the page by default ?

[jpic]

#94 allows to have dss to not reload the page when the session expires.

This can leave sensible data on the screen for a hacker to right click -> inspect -> delete whatever blocks the view or leave sensible data in memory that a hacker could obtain remotely.

However, it delivers a lot better user experience, particularly when the page has taken steps to setup.

I wonder how many of you are running a fork of the script that doesn't reload the page ?

I would really like this to become the default, in this case, would it be necessary for you that sensible data be encrypted during the time the session is locked if the page isn't reloaded to a blank login script as it is today ?

I'm asking "you" for everybody reading this, I haven't had this script in production for ages, if anybody wants to step up as a maintainer it's a golden opportunity that will make you learn things in life that you could not learn in any other way !

[mattbo]

I wrote #94, so I'm biased. That said, I don't think this should be the default, just an option. It is significantly less secure since the contents of the page remain visible. Moreover, in the case of a single-page app some strange behavior could result (ajax calls failing because login is required).

To be clear, this is designed intentionally to require a login before moving to the next page. The popup informing the user that their session has expired can be closed and the current page contents will remain visible. A password will not be required until the user requests another page.

[claytondaley]

If the purpose of this tool were not security (e.g. Django core), it might make sense to select defaults based on common configurations (or user friendliness). However, users make a deliberate choice to add session security and they do so for security first and foremost. Our defaults and decision process should reflect that reality.

I believe the defaults should be the most secure setting. If any of those defaults are especially unfriendly to users, documentation (e.g. a tutorial) should suggest a "typical" configuration -- side by side with the appropriate caveats.

[jpic]

#94 will be fine for the time being then, but perhaps we should name the variable "protect_data" or something even more relevant to the user as suggested by @claytondaley ?

Thanks for your feedback <3