-
Notifications
You must be signed in to change notification settings - Fork 45
[WIP] Start drafting sudo mode RFC #10653
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
base: main
Are you sure you want to change the base?
Conversation
A couple of thoughts:
|
**Option 1 - Treat it as a new `Login`** | ||
|
||
Given that we have an existing flow for authenticating users, we could treat re-authentication as a new login flow which, once complete, swaps in a new `UserSession`. | ||
|
||
We would ideally link the new `Login` to the previous one so we can distinguish it as a re-authentication, apply different rules (e.g. only requiring one factor), and maintain a chain of `Login` records (for auditing purposes). |
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.
I think this a good idea, we could do something like voided_by_id
to store the ID of the past Login
|
||
<img src="login_notification_email.png" width="200"/> | ||
3. How do we want to handle sudo actions for users that are being impersonated? Is re-authenticating the impersonator enough? | ||
- _Opinion_: We should strongly consider making this question go away by capping impersonated sessions to 2 hours. I don't think there's a use case for having these persist for longer than that. |
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.
Yes- this is a good idea
<img src="login_notification_email.png" width="200"/> | ||
3. How do we want to handle sudo actions for users that are being impersonated? Is re-authenticating the impersonator enough? | ||
- _Opinion_: We should strongly consider making this question go away by capping impersonated sessions to 2 hours. I don't think there's a use case for having these persist for longer than that. | ||
4. Should re-authentications appear in activities? |
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.
Yes but with custom copy
1. We currently show users a list of their sessions including how long ago they logged in. Should we also surface information about re-authentications? | ||
|
||
<img src="sessions.png" width="200"/> | ||
2. We send users an email when there is a new login on their account. Would we want to do the same for re-authentications? |
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.
We normally only do this if the context is unrecognised, I think it's ok to not do this
|
||
**Open questions** | ||
|
||
1. We currently show users a list of their sessions including how long ago they logged in. Should we also surface information about re-authentications? |
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.
Yes but imo we should flatten them into one Login
## Summary of the problem Admin users have the ability to impersonate other users for debugging and support purposes. However while thinking through the implications of implementing a sudo mode (see #10653 (comment)) we realized these impersonated sessions live for as long as the impersonated user's `session_duration_seconds`, which could be much longer than necessary. ## Describe your changes - `spec/rails_helper.rb` now eagerly-loads all files in `spec/support` so we can put shared code in there - Added `SessionSupport` module to make writing controller tests easier - Updated the `:user_session` factory to populate the `session_token` field - Updated the logic in `SessionHelper#sign_in` to cap impersonated sessions to one hour - Added a test for the above --------- Co-authored-by: Manu G <[email protected]>
Summary of the problem
#6346
Describe your changes
Rendered