-
Notifications
You must be signed in to change notification settings - Fork 122
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Allow confirming email in a different browser (#1265)
* Allow confirming email in a different browser **Why**: Some people might visit the site via a Service Provider (SP) in one browser, but open the email confirmation link in a different browser. This means that anything that was previously stored in the session in the first browser won't be available in the second browser. The consequence is that the user won't be redirected back to the SP after they finish creating their account. **How**: - Add a new ServiceProviderRequest DB table When a request is made from an SP, whether it's via SAML or OpenID Connect, we create a new ServiceProviderRequest with the following attributes: the full request URL, a random unique UUID (because it's not guaranteed that separate requests will have a unique identifier attached to them), the issuer, and LOA. We also store these same attributes in the session to support the sign in scenario (as opposed to account creation). Then, we check to see if the user is fully authenticated, and if not, we redirect them to the `/sign_up/start` page, and include the request_id in the params, as well as in the links on that page that point to the account creation and sign in pages. Note that I moved the logic that determines whether or not the landing page should appear, from the sessions controller to the SAML and OpenID Connect controllers, since they are the ones that know where the user should go. This adheres to the Tell, Don't Ask principle, and allows us to remove the `show_start_page` key from the session. When the user chooses to create an account, the form contains the request_id in a hidden field so it can pass it on to the registrations controller. To include the request_id in the confirmation email, I had to create a new method based on the one Devise uses, but with the ability to pass in the request_id. Since Devise automatically sends the confirmation email when the user is created (via a callback), I had to override the original method to do nothing. By having the request_id in the email, that means that if the user visits the confirmation URL in a different browser, we can go back to storing the SP info in the session by looking up the ServiceProviderRequest whose uuid matches the `_request_id` parameter from the URL in the email. By going back to using the session from then on, it frees us from having to keep passing in the request_id in URLs and in forms. This is done in `EmailConfirmationsController#process_valid_confirmation_token`. Note that the request_id is prefixed with an underscore in the email to make sure that the URL ends with the confirmation token. By default, Rails sorts params in `link_to` helpers alphabetically, but we don't want `request_id` to come last because if the user chooses to copy the link instead of clicking it, and if they don't copy it correctly, the app won't find the ServiceProviderRequest, whereas an invalid confirmation token will display an error to the user. Once the user finishes creating their account, when they click the button to continue to the SP, the app makes the original SP request again, calling the `before_action`s in the SAML and OpenId Connect controllers a second time. However, we don't want to create a new ServiceProviderRequest because we want to be able to delete the original one after the user goes back to the SP. We don't want the ServiceProviderRequests table to grow indefinitely. The only way to know for sure whether or not a ServiceProviderRequest that matches the request URL already exists is to query on its `url` field. The problem is, given that we want to index that field since it will be queried on every SP request, the url field value is too big for the Postgres btree index. There are solutions to this problem (that I haven't implemented before), but I didn't feel it was worth the trouble when we can rely on the presence of `sp_session[:request_id]` to determine whether or not a new ServiceProviderRequest should be created or not. We also use the `sp_session[:request_id]` to determine which ServiceProviderRequest to delete by find a matching uuid. Then, we can safely delete the `:sp` Hash from the session. By keeping track of the SP via the request_id, we can also remove the session timeout code and flash message that dealt with the scenario where a user makes a request from an SP, but then remains on the sign in page for longer than 8 minutes. Note that all this does is preserve the branded experience on the sign in page. Allowing the SP info to be restored after sign in will be implemented in a separate PR. Note that this doesn't include the same fix for the scenario where a user opens the password reset link in a different browser. That will be in a separate PR.
- Loading branch information
Showing
54 changed files
with
606 additions
and
212 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
module FullyAuthenticatable | ||
def confirm_two_factor_authenticated(id = nil) | ||
return redirect_to sign_up_start_url(request_id: id) unless user_signed_in? | ||
|
||
return prompt_to_set_up_2fa unless current_user.two_factor_enabled? | ||
|
||
prompt_to_enter_otp | ||
end | ||
|
||
def delete_branded_experience | ||
ServiceProviderRequest.from_uuid(sp_session[:request_id]).delete | ||
session.delete(:sp) | ||
end | ||
end |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.