-
Notifications
You must be signed in to change notification settings - Fork 5
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
Account self-deletion #652
Conversation
We always use the method from the password authenticator whenever we do this check; there is no need for this method in this class.
This adds a new table for account deletion tokens, a new persistence manager, an endpoint to request the token via, and adds assorted other methods for generating secure random tokens and creating the emails. There are still questions about whether the endpoint is in the right place, and whether the methods should live elsewhere in the tree of managers.
The endpoint confirms the deletion token is valid and then deletes the logged-in user's account and clears the login cookies.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #652 +/- ##
==========================================
+ Coverage 34.16% 34.39% +0.23%
==========================================
Files 519 521 +2
Lines 23264 23378 +114
Branches 2854 2863 +9
==========================================
+ Hits 7947 8042 +95
- Misses 14515 14528 +13
- Partials 802 808 +6 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pair-reviewed with @axlewin.
The general approach looks good. I think I would lean towards a shorter expiry time, especially since we're requiring login on the basis that the user will probably act on it quickly.
I don't have a strong opinion about where the code lives, I would perhaps lean towards the user facade/manager so it's in the same place as the account creation logic but this is also fine.
Some integration tests for various scenarios (happy path, using another user's token, expired token) would be nice.
src/main/java/uk/ac/cam/cl/dtg/segue/dao/users/PgDeletionTokenPersistenceManager.java
Outdated
Show resolved
Hide resolved
src/main/java/uk/ac/cam/cl/dtg/segue/api/managers/UserAuthenticationManager.java
Outdated
Show resolved
Hide resolved
Let's bring the time down to 1 day, as for password resets. Then I will have a go at adding some integration tests. |
Instead of mocking the deletion persistence manager, use a real one. We also need to mock the request session in order to invalidate it without errors.
# Conflicts: # src/main/resources/db_scripts/postgres-rutherford-create-script.sql # src/test/resources/test-postgres-rutherford-data-dump.sql
This PR adds two new endpoints:
I have several questions about this implementation: