-
Notifications
You must be signed in to change notification settings - Fork 10
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
One login db session #10203
One login db session #10203
Conversation
c5f1f1a
to
46f139e
Compare
end | ||
|
||
def require_authentication | ||
current_candidate || resume_session || request_authentication |
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.
current_candidate is here to make the one login feature flag activation seamless. So if a candidate is loged in with magic link, they will still be logged in after switching the one login on.
The reverse is not true, if we switch off one login feature flag, we will log out the current candidates
It's also here for impersonation. Current_candidate will be used for impersonation.
So db backed session is used for candidates but support users impersonation will still be using cookies/session
before_action :redirect_to_candidate_sign_in_unless_one_login_enabled | ||
allow_unauthenticated_access# only: %i[callback bypass_callback] |
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 need to allow requests to these endpoints without requiering authentication to be able to login the candidate and also log out the candidate by just calling these endpoints.
There are cases where the user is logged in in one admin but not in our system because of an error in our system, so we need to be able to call sign-out endpoint to log them out of one login
redirect_to auth_one_login_sign_out_path | ||
rescue StandardError => e | ||
# We can't attach an error message to the session because in some cases we don't create a session if there's an error | ||
session_error = SessionError.create!( |
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 can't attach an error message to the session because in some cases we don't create a session if there's an error
9fcd501
to
199728f
Compare
@@ -115,6 +115,29 @@ | |||
], | |||
"note": "" | |||
}, | |||
{ |
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.
Brakeman raises these warning but I don't think there's really a risk here since we have total control over what's happening
We need to think about session expiry, we will have old sessions in our DB without implementing an expiration feature |
5e0adfc
to
97776e2
Compare
80ca8c1
to
0fd57eb
Compare
In testing the one login integration, we discovered that having session backed login is not ideal. There is a risk that the session gets too big, over 5000 bytes. To fix this, we are switching to Database backed sessions. This is inspired by the rails 8 new db backed sessions. Most of the logic is in this concern `Authentication` using this and before filters in controllers we control the one login mechanism. We will use DB backed session for the normal candidate flow. Impersonation will still use cookie session. This means that deleting the session from the DB logs out the user. Switching between one login and magic link auth system will be seamless as we always check `current_candidate`. We will still save some data in the session but it will be very little, just ids rather than big tokens. The session size decreased from roughly 3224 to 600
0fd57eb
to
1adb434
Compare
Nice one! I'm really glad we'll have db backed sessions from now. As mentioned elsewhere, we are missing a session expiry strategy. But I'm happy for this to go in as it is, behind a feature flag, in the meanwhile. |
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.
Nice work 👌 I love that this matches the Rails authentication 😍
I echo @elceebee concerns about expiring session but this can be added later.
It will be worth monitoring this in environments where OneLogin is in use before going to production
Context
In testing the one login integration, we discovered that having session backed
login is not ideal. There is a risk that the session gets too big, over 5000
bytes. To fix this, we are switching to Database backed sessions.
This is inspired by the rails 8 new db backed sessions.
Most of the logic is in this concern
Authentication
using this and beforefilters in controllers we control the one login mechanism.
We will use DB backed session for the normal candidate flow. Impersonation will
still use cookie session.
This means that deleting the session from the DB logs out the user.
Switching between one login and magic link auth system will be seamless as we
always check
current_candidate
.We will still save some data in the session but it will be very little,
just ids rather than big tokens.
The session size decreased from roughly 3224 to 600
Screencast.2025-01-02.14.23.36.mp4
Changes proposed in this pull request
Migrations, models and controllers
Guidance to review
Go on QA and test the integration. It should work like before.
Things to check