Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access token invalidation should be disabled by default in 2.x #3068

Closed
2 tasks done
bajtos opened this issue Jan 4, 2017 · 3 comments
Closed
2 tasks done

Access token invalidation should be disabled by default in 2.x #3068

bajtos opened this issue Jan 4, 2017 · 3 comments
Assignees
Milestone

Comments

@bajtos
Copy link
Member

bajtos commented Jan 4, 2017

As described in #3048, adding automatic access token invalidation to 2.x is viewed as a breaking change by some of our users.

We should add a new feature flag (model-level setting?) to 2.x to control whether access token are invalidated or not. When this flag is not set, a warning should be printed to notify users about a potential security vulnerability.

In 3.0, we should throw an exception when this flag is set to false, so that users upgrading from 2.x to 3.0 are forced to upgrade their code to support our automatic token invalidation.

Tasks

@bajtos bajtos self-assigned this Jan 4, 2017
@cgole cgole added this to the Sprint 27 milestone Jan 10, 2017
bajtos referenced this issue Jan 19, 2017
Invalidate all existing sessions (delete all access tokens)
after user's password was changed.
@timlind
Copy link

timlind commented Jan 20, 2017

Is documentation update included in the above tasks? It's the first place I went to look when it broke.

@bajtos
Copy link
Member Author

bajtos commented Jan 20, 2017

@timlind Is documentation update included in the above tasks? It's the first place I went to look when it broke.

Good point! What page would you recommend to change? Would you mind contributing this change yourself? In my experience, documentation contributed by users tends to be the best one, because users know best what and where they were looking for in the docs.

@bajtos
Copy link
Member Author

bajtos commented Jan 20, 2017

Actually, let's keep the documentation as part of the follow-up story #3112

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants