Skip to content
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

Deploy RC 71 to staging #2666

Merged
merged 44 commits into from
Nov 20, 2018
Merged

Deploy RC 71 to staging #2666

merged 44 commits into from
Nov 20, 2018

Conversation

stevegsa
Copy link
Contributor

Hi! Before submitting your PR for review, and/or before merging it, please
go through the checklists below. These represent the more critical elements
of our code quality guidelines. The rest of the list can be found in
CONTRIBUTING.md

Controllers

  • When adding a new controller that requires the user to be fully
    authenticated, make sure to add before_action :confirm_two_factor_authenticated
    as the first callback.

Database

  • Unsafe migrations are implemented over several PRs and over several
    deploys to avoid production errors. The strong_migrations gem
    will warn you about unsafe migrations and has great step-by-step instructions
    for various scenarios.

  • Indexes were added if necessary. This article provides a good overview
    of indexes in Rails.

  • Verified that the changes don't affect other apps (such as the dashboard)

  • When relevant, a rake task is created to populate the necessary DB columns
    in the various environments right before deploying, taking into account the users
    who might not have interacted with this column yet (such as users who have not
    set a password yet)

  • Migrations against existing tables have been tested against a copy of the
    production database. See LG-228 Make migrations safer and more resilient #2127 for an example when a migration caused deployment
    issues. In that case, all the migration did was add a new column and an index to
    the Users table, which might seem innocuous.

Encryption

  • The changes are compatible with data that was encrypted with the old code.

Routes

  • GET requests are not vulnerable to CSRF attacks (i.e. they don't change
    state or result in destructive behavior).

Session

  • When adding user data to the session, use the user_session helper
    instead of the session helper so the data does not persist beyond the user's
    session.

Testing

  • Tests added for this feature/bug
  • Prefer feature/integration specs over controller specs
  • When adding code that reads data, write tests for nil values, empty strings,
    and invalid inputs.

jmhooper and others added 30 commits November 5, 2018 14:03
**Why**: So that users will know when their personal key is being used
to sign in and be aware of any suspicious activity around their personal
key.
**Why**:
Now we send a text when a user generates a new personal key.
…DO (#2642)

**Why**: So the user is not presented with 2FA options they can't use.

**How**: Display the security key option as hidden in the list of 2FA options.  Use javascript to determine if FIDO is supported.  If it is supported unhide the security key option.  If it is not supported make sure that the next 2FA option is selected by default.
**Why**: The scale wasn't updated after the spec changed
LG-570 Update typography scale to match spec
**Why**:
When a controller uses Strong Parameters such as:
`params.require(:user).permit(:email)`, the `user` param is assumed to
be a Hash, but it's easy for a pentester (for example) to set the
`user` param to a String instead, which by default would raise a 500
error because the String class doesn't respond to `permit`.

**How**:
To get around that, we monkey patched the Ruby String class to raise an
instance of `ActionController::ParameterMissing`, which will return a
400 error. 500 errors can potentially page people in the middle of the
night, whereas 400 errors don't.

Note that Devise handles this scenario gracefully in SessionsController,
but because it determines whether or not to call `permit` based on
whether or not the object responds to `permit`, the Devise code will
end up calling `permit` because all Strings respond to it now after our
monkey patch. This is why the `invalid_sign_in_params_spec` had to
change.
**Why**: The 2FA options list for login does not display FIDO when it is not supported.  However the code bypasses the selection list and takes you to the preferred option that you have configured.  A redirect was added to take the user back to the selection list but it was added to the setup js and not the authenticate js

**How**: In webauthn-authenticate.js, redirect to /login/two_factor/options when the user is on the webauthn login screen and FIDO is not supported.
**Why**: To allow the user to check for unusual activity on their
account page, and to make it easier for us to troubleshoot security
issues.
monfresh and others added 12 commits November 13, 2018 20:41
**Why**: As a user I don't want to be allowed to enter less than 12 characters for a new password even though it returns an error after I submit.

**How**: Update the pw-strength.js to check for password length.
**Why**: As a user I want to see events in my account history in my local timezone

**How**: Since we do not store a user's timezone, update timestamps to the user's local timezone by adding client side javascript which uses the timezone of the browser.  Use the local_time gem.  Set the locale in the javascript by grabbing it from the path in the url.  Add bug fixes and internationalization.
**Why**: To make the delete option less prominent since the user will not be able to recover any information linked to their account.

**How**: Use the same format as the confirmation of delete screen at the beginning of the process.
**Why**: So that user's can be aware of any potential suspicious
activity associated with their account.
**Why**: We want the user to be able to add multiple phone numbers to their account without replacing any already configured.

**How**: Replace the generic user.phone_configurations.first, which assumed one phone, with specific phone ids.  Pass these ids when managing, updating, and authenticating.  Create a new screen for adding a phone fashioned after the existing edit phone screen.
@stevegsa stevegsa merged commit 2738a9e into stages/staging Nov 20, 2018
@mitchellhenke mitchellhenke deleted the stages/rc-2018-11-22 branch December 28, 2021 16:05
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.

5 participants