Skip to content

Deployment to staging: patch for 1.008#1546

Closed
gemfarmer wants to merge 3 commits intostages/stagingfrom
stages/rc-2017-07-10-patch-3
Closed

Deployment to staging: patch for 1.008#1546
gemfarmer wants to merge 3 commits intostages/stagingfrom
stages/rc-2017-07-10-patch-3

Conversation

@gemfarmer
Copy link
Copy Markdown
Contributor

@gemfarmer gemfarmer commented Jul 13, 2017

Deploy patch to staging for 1.008. These changes will also be part 1.009.

Changes include:

monfresh added 3 commits July 13, 2017 11:20
**Why**: For consistency with the behavior during account creation
cancellation.

**How**:
- Add a new controller and route for signing the user out without having
to go through `SamlIdpController#logout` since there is no single logout
to be performed in this scenario
- Replace the URL of the Cancel link to point to this new route

(cherry picked from commit ae68355 #1526)
**Why**: We noticed some users were running into an exception
while trying to set their password. It turned out they were
signing up for multiple accounts in the same session, but
using different browsers, which is a common use case for users
starting the process in a mobile app, and then confirming their
email in a separate app or mobile browser.

The bug was that we were only storing the request in the DB if the
session didn't already contain the `request_id`, and we also deleted
the request after a successful redirect back to the SP. Here's a
concrete example, which I wrote a test for:

- User starts by entering their email in browser 1, request 1 is stored
in the DB and in the session
- User confirms their email in browser 2, which looks up request 1 in
the DB, and stores it in the session
- User continues the account creation process successfully and continues
on to the SP. At this point, request 1 is deleted from the DB
- User goes back to browser 1 and makes a new request while the original
session is still alive. Since the session is still alive and still
contains request 1, the app doesn't store this new request, but the same
`request_id` is passed on to the email confirmation
- User confirms their email in browser 2, which passes because we don't
validate the request_id at this point.
- User tries to create their password, but when they submit the form,
they get an exception because the app is trying to look up the request
in the DB that matches the orginal `request_id`, but it was deleted
earlier.

**How**: Always store a request in the DB every time a new request is
made by the SP. Don't reuse requests. The reason we reused requests
before was to make it easier to delete requests in the DB that were no
longer needed, but I obviously didn't think it through. We'll need to
come up with a rake task or some other way to prevent the
`ServiceProviderRequests` table from growing too large.

(cherry picked from commit e38a3df #1542)
**Why**: Before, we were only responding with a 404 to requests for
the HTML format, and we noticed 500 errors when browsers requested
nonexistent PNG and CSS files.

(cherry picked from commit 778ac7a #1543)
Copy link
Copy Markdown
Contributor

@zachmargolis zachmargolis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@gemfarmer
Copy link
Copy Markdown
Contributor Author

Closing in favor of #1552

@gemfarmer gemfarmer closed this Jul 17, 2017
@mitchellhenke mitchellhenke deleted the stages/rc-2017-07-10-patch-3 branch December 28, 2021 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants