Promotion of current master to stages/qa#1182
Merged
Conversation
**Why**: To make the code easier for the user to write down
* Adds text to about why recovery code is important **Why**: TO make absolutely sure our users understand why saving their recovery code is crucial to keeping their account accessible * Adding accordion **Why**: to make the code work
**Why**: Support the OpenID Connect spec **How**: - Bring back identities.ial column to preserve ial - Add LOA1 => LOA3 upgrade to OpenID Connect Flow
**Why**: When attempts == max-1 and window has expired, counter was not resetting after successful resolution.
**Why**: It's time to get real.
**Why**: Add fieldset and legend for accessibility. Also small bug fix that reflects the correct yes/no output for the checkbox questions. Currently they are always being displayed as Yes no matter if they are checked or not.
**Why**: It conflicts with our "keep me signed in" page refresh button
**Why**: To reflect current designs
**Why**: Causes confusing behavior
**Why**: To provide additional context for edit links
**Why**: To link radio buttons to instructions for screen readers.
* Use rack in Profile. Explicitly use port 3000. * Added missing rack middleware for development. * Remove debugger rack config. See: #909 (comment)
**Why**: It would be broken functionality otherwise. **How**: Define a new context called `reauthentication` in the change factor flow because `TwoFactorAuthenticable#check_already_authenticated` should only be called in the initial authentication context.
**Why**: When the `rake` command is invoked, it parses all rake tasks, even if they're not being called directly. The user_flows rake task requires RSpec, and is not meant to be run in production. By ignoring production, we suppress error messages due to RSpec not being present, which aren't relevant in production. In development, we don't want to rescue the LoadError. We want to make sure the rake task aborts because if RSpec is not present, it's a problem.
**Why**: Track vendor rationales for success/failure in each verification step.
**Why**: To match latest visual designs
**Why**: We should LOA3 users the recovery code after the IDV flow. No need to show them twice.
**Why**: We expect active_profile.verified_at to not be nil
* Uses same recovery code visuals on loa3 **Why**: To present a consistent interface to the user * Renames spec helper, fixes heading i18n refs **Why**: To keep consistency with our other recovery code management screen
**Why**: Missed this spot in #1003
* Adds int Dashboard to SPs * Adds int Demo SP to service providers
**Why**: Generating a new recovery code will render the de-activated profile useless. **How**: Catch the exception thrown when a valid recovery code cannot be used to decrypt the PII, and prevent users from unintentionally creating a new recovery code when they have a de-activated profile.
**Why**: To prevent stale id_tokens from trying to access PII
**Why**: Better UX
**Why**: Presenters make the views a little cleaner Don't show recovery code, unconfirmed phone links **Why**: The user shouldn't be able to use a recovery code when confirming a changed phone number, nor should they be able to select the 'use another phone' choice when reauthenticating after choosing a new phone number Moves session context + related methods to module **Why**: Methods were getting duplicated across modules Adds new method to check for auth context only **Why**: The `authentication_context?` needs to handle two types of auth contexts, and we don't want to keep cluttering up multiple files with hardcoded string references Adds presenters for phone view **Why**: To consolidate logic of how we show fallback otp links and associated help text to the user Adds authenticator presenter **Why**: To consolidate logic for displaying otp fallback links and help text
* Adds fix for permissions in /srv/idp * Adds INT environment to deployment stages * Makes :deploy a string for consistency
* Adds authenticator app tooltip **Why**: To ensure users understand what the app is, and how they can use it * Pass optional explicit view context to presenter **Why**: It is the easiest way to allow the presenter to have access to mehtods inside view helpers
**Why**: The sentence didn't make sense without these changes
**Why**: The `worker_health_checker` method was not hit due to the stubbing. **How**: - Remove the method since it's not really needed - stub `WorkerHealthChecker` directly
**Why**: Tidiness is a virtue. Code Climate was reporting this method as untested, and in this case, it's because it wasn't used.
**Why**: We don't care about this particular offense.
**Why**: To have complete code coverage.
**Why**: For complete test coverage
* Add helper method to specs for recovery code entry **Why**: dry up the tests and encapsulate the recovery code entry logic * Add partial + update reactivate_profile controller **Why**: Multiple views need the ability to enter a recovery code, so we break it out. The `ReactivateProfileController` needed to be aware of `recovery_code` as an array * Fix specs, add simple_form ext, code clean up **Why**: Needed simple form hooks to be able to have multiple text inputs described by a single label, with discrete error classes on each * Make the RecoveryCodeForm behave more like a model **Why**: To leverage simple form * Directly set the attrs object **Why**: In case `recovery_code: nil` is passed in
* Improve flash message when page is refreshed **Why**: To give users more context on why we refresh the page and clear the form inputs.
**Why**: To allow SPs to be more specific in the PII they request
**Why**: The default behavior of clicking an a tag causes the page to scroll to the top
* Remove recovery code flash msg from profile **Why**: This particular message should only display on the personal key page. * Update test **Why**: Update flash message
**Why**: We want the cookie to expire if/when the browser is closed, but the Redis server-side expiration to expire after the configured number of minutes.
**Why**: To use the new ones only
**Why**: Now that Service Providers are stored in the DB, along with all of their attributes, we can read the attributes directly from the DB, as opposed to storing them in the session.
**Why**: Make sure pages are using semantic HTML
**Why**: To be consistent with style guide
**Why**: Legacy dbs need data migration.
**Why**: I had mistakenly prevented it due to my misunderstanding of how this works. The dashboard app is correctly only allowing admins to set this attribute, so it's safe for the IdP to allow it through.
**Why**: Our SORN has been officially published
**Why**: Ahoy excludes bots by default, and it detects Locust as a bot. Luckily, Ahoy makes it easy to customize what gets excluded by overriding the `exclude?` method. In this case, we're telling Ahoy to allow everything during load testing. Otherwise, use the default settings. This allows us to better simulate server load.
**Why**: For a consistent experience
**Why**: There is no LOA0 and some SPs are using off-the-shelf integrations that do not allow for customization.
andrewhughey
approved these changes
Mar 8, 2017
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotion of current
master@a46ad8tostages/qaWhy
Continuous deployment
How
QA on https://idp.dev.login.gov/
💁 I will be force pushing to stages/qa after this lands to clean up the gitref mismatch caused by the first migrations squash we hotfixed.