LG-233 Add account access details to account page

[monfresh]

Why: Through the Devise gem, the DB already captures the info listed
below. Displaying it to the user is a trivial change, and makes it
easier for the user and for the customer contact center folks to verify
the validity of claims such as "I've been hacked".

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

• For DB changes, check for missing indexes, check to see if the changes
  affect other apps (such as the dashboard), make sure the DB columns in the
  various environments are properly populated, coordinate with devops, plan
  migrations in separate steps.

• For route changes, make sure GET requests don't change state or result in
  destructive behavior. GET requests should only result in information being
  read, not written.

• For encryption changes, make sure it is compatible with data that was
  encrypted with the old code.

• For secrets changes, make sure to update the S3 secrets bucket with the
  new configs in all environments.

• Do not disable Rubocop or Reek offenses unless you are absolutely sure
  they are false positives. If you're not sure how to fix the offense, please
  ask a teammate.

• When reading data, write tests for nil values, empty strings,
  and invalid formats.

• When calling redirect_to in a controller, use _url, not _path.

• 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.

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

[monfresh]

Screenshot here:

[brodygov]

Really happy to see us exposing more information like this. Not necessary for MVP, but it's also useful to include location and UA/browser/OS. So you might write it as:

Login on Sept. 19, 2018 at 12:00 from Washington DC using Chrome on MacOS (IP address 203.0.113.1)

[monfresh]

Yeah, for sure. I was going to tackle location next. The browser info is a great idea as well, as is the sentence format. It would be great to work with the design team on the best way to present this info.

[clarebayley-gov]

I really like this, and +1 to the sentence format Brody suggested. I believe either John or Ryan would have bandwidth for this right now if you want design eyes.

[donjo]

I like the sentence structure @brodygov suggested if we can get all of that information. If that starts to be too long under certain circumstances we could present the time in a truncated format that provided a more exact time upon hover/tap

So something like

Login from Washington DC using Chrome on MacOS (IP Address 67.67.67.67)              4 days ago

[monfresh]

@donjo Here is an updated screenshot:

I created a new Login History section that can be sorted independently of the other account events.

Currently, we don't record the user agent in the DB when the user signs in, so for now, we only show IP and location. In a future PR, I will introduce a new table that will capture user agent, IP and timestamp for each login.

Here is the Spanish version:

And French:

I dropped the preposition for French because it's not always "de" depending on the location.

If either city or state are missing, we only show the country. If no location is available, we show "unknown location":

Thoughts?

[donjo]

I like it. I think separating the login events from account events is a good idea for readability and makes it a bit easier for support folks to direct people to the right section if they're working through a problem together.

[monfresh]

@konklone @brodygov I downloaded the free GeoLite2 City database from https://dev.maxmind.com/geoip/geoip2/geolite2/ and included it in this repo. Are there any issues with doing that?

For more accuracy, we might want to buy the premium version.

[brodygov]

Ha, didn't see your comment. I'd suggest delivering large files like that by some other mechanism, like S3 or a separate github repo for binary blobs. Otherwise you're permanently inflating the identity-idp repo size and time it takes to clone.

[donjo]

Approved from design perspective. Ping any engineers if you need additional code reviewing.

[monfresh]

@brodygov I agree that it would be preferable to have the large file somewhere else. I put it in S3 and updated our deploy/activate script to download the file. Changes are here: 5005577

Let me know what you think.

[konklone]

@monfresh Yes, we should p-card the premium version of this data so that we're more accurate, and refresh it on at least an annual basis. cc @jprisby1 @oghaffari

[konklone]

(But I wouldn't consider that a blocker for this work at all. Let's get it out there, and update accuracy later.)

[monfresh]

The problem with not storing the DB in the repo is that we can't test this feature locally. Here are some solutions I could think of:

1. Use Git Large File Storage. https://git-lfs.github.com/
   I'm not sure if this automagically works for deployed apps or if we also need to download the file from S3
2. Add instructions to the README for downloading the file locally for testing and add it to .gitignore
3. Update geocoder initializer to use something else in development so that it doesn't have to depend on the file

Thoughts?

[jmhooper]

Could we add something to bin/setup to download the free one?

[monfresh]

@jmhooper Good idea. Implemented here: ff0b6d6

PTAL

[jmhooper]

We'll have to make this bucket exists in both the sandbox and prod account

[jmhooper]

It was in the sandbox account's bucket. I just uploaded it to the prod account.