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

LG-13132 Adds property to SP redirect initiated event #10560

Merged
merged 21 commits into from May 14, 2024

Conversation

kevinsmaster5
Copy link
Contributor

🎫 Ticket

Link to the relevant ticket:
LG-13132

🛠 Summary of changes

Creates a session variable when visiting Log in page. This differs from the session[:session_started_at] value because it gets revised upon returning to the Log in page. The latter exists to service other features like determining session expiration for example.
A duration between most recent visit to the Log in page and execution of SP redirect is calculated and passed along to AnalyticsEvents.

The purpose is to create an accurate account of the time it takes a user directly from signing in to conclusion at the SP. It will support a new Cloudwatch log dashboard widget.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

  • In the local terminal run make watch_events
  • Using either OIDC or SAML Sinatra log into the local instance, authenticate and proceed to the SP
  • Check the log for presence of a sign_in_duration_in_seconds property that has a value that you expect
  • Notice that if you leave the sign in page and come back to it before signing in the time differs from session_duration

Screenshot 2024-05-06 at 2 32 35 PM (2)
I forgot my password which caused a 10 second delay recoreded in session_duration.

Comment on lines 219 to 221
sign_in_duration_seconds: (Time.zone.now - Time.zone.parse(
session[:sign_in_page_visited_at] || Time.zone.now.to_s,
)).seconds.to_i.round(2),
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. if the session[:sign_in_page_visited_at] gets cleared or wiped, this will be zero because it's .now. What if we left it nil when is no session[:sign_in_page_visited_at] so that we can tell the difference between missing data and zero?

  2. .to_i.round(2) is redundant, because integers can't be rounded. Is the goal to have 2 decimals of floating point precision?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  1. That's a good point. It might also be helpful to get an idea of how often someone is bouncing to a different browser so instead of the data showing a huge spike it will have some nil values to query against. 🤔

  2. I didn't realize converting to integer already truncates https://dev.to/dawncronin/number-conversions-in-ruby-1ned#:~:text=Ruby%20has%20a%20built%20in,will%20round%20to%20two%20decimals. "the to_i conversion truncates the number,"

@@ -28,3 +28,8 @@ def delete_auth_count(request_id)
session[:sp_auth_count].delete request_id
end
end

def sign_in_duration
Copy link
Contributor

Choose a reason for hiding this comment

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

this is defined outside of the concern aka it's making a method name at global scope, I don't think that']s what we want

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Definitely not! Good catch.

@@ -52,6 +52,7 @@
before do
stub_sign_in user
session[:sign_in_flow] = sign_in_flow
session[:sign_in_page_visited_at] = (Time.zone.now - 2.minutes).to_s
Copy link
Contributor

Choose a reason for hiding this comment

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

another fun helper:

Suggested change
session[:sign_in_page_visited_at] = (Time.zone.now - 2.minutes).to_s
session[:sign_in_page_visited_at] = 2.minutes.ago.to_s

@@ -131,6 +132,7 @@
with(
'SP redirect initiated',
ial: 1,
sign_in_duration_seconds: 120,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm worried about clock skew contributing to flakey specs here, we probably want to freeze time with a specific time and specifically specify 120 seconds ago for the time

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would that mean wrapping the expect() blocks like this?

diff --git a/spec/controllers/openid_connect/authorization_controller_spec.rb b/spec/controllers/openid_connect/authorization_controller_spec.rb
index 7b1ca74e73..fdc40c393d 100644
--- a/spec/controllers/openid_connect/authorization_controller_spec.rb
+++ b/spec/controllers/openid_connect/authorization_controller_spec.rb
@@ -142,15 +142,17 @@ RSpec.describe OpenidConnect::AuthorizationController, allowed_extra_analytics:
               user_sp_authorized: true,
               code_digest: kind_of(String),
             )
-            expect(@analytics).to have_logged_event(
-              'SP redirect initiated',
-              ial: 1,
-              billed_ial: 1,
-              sign_in_duration_seconds: 60,
-              sign_in_flow:,
-              acr_values: 'http://idmanagement.gov/ns/assurance/ial/1',
-              vtr: nil,
-            )
+            freeze_time do
+              expect(@analytics).to have_logged_event(
+                'SP redirect initiated',
+                ial: 1,
+                billed_ial: 1,
+                sign_in_duration_seconds: 60,
+                sign_in_flow:,
+                acr_values: 'http://idmanagement.gov/ns/assurance/ial/1',
+                vtr: nil,
+              )

Unrelated but I arbitrarily changed to 60 seconds trying something different.
session[:sign_in_page_visited_at] = 1.minute.ago.to_s

Copy link
Contributor

Choose a reason for hiding this comment

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

freeze_time usually goes in an around or a before block

@kevinsmaster5 kevinsmaster5 force-pushed the kmas-lg-13132-sp-redirect-duration branch from 9c007d0 to 4d0d82f Compare May 7, 2024 18:42
@kevinsmaster5 kevinsmaster5 marked this pull request as ready for review May 8, 2024 20:21
@aduth aduth requested a review from a team May 9, 2024 16:35
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a spec/controllers/concerns/sign_in_duration_concern_spec.rb with test coverage?

@@ -107,6 +114,7 @@

context 'with ial1 requested using acr_values' do
it 'tracks IAL1 authentication event' do
travel_to Time.zone.now + 15.seconds
Copy link
Contributor

Choose a reason for hiding this comment

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

to make the time easier to track, I would consider using a let block to freeze a specific time

so like

let(:now) { Time.zone.now)

around do |ex|
  freeze_time(now) { ex.run }
end

...

it 'tracks events' do
  travel_to now + 15.seconds
  ...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see. I have added that as a let block and updated those tracked events. Thanks!


def sign_in_duration_seconds
return unless session[:sign_in_page_visited_at]
(Time.zone.now - Time.zone.parse(session[:sign_in_page_visited_at])).seconds.to_i
Copy link
Member

Choose a reason for hiding this comment

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

Non-blocking: I feel like it'd be nice to have a little bit of sub-second precision here, since I'd expect the typical value to be somewhat low where precision matters, especially if this is always rounding down. Alternatively we could seconds.round.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see. I have it goint .to_f now that seems to be more towards precision. What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I think that's better.

That also brings it a lot closer into alignment with the value for session_duration as well, which is nice.

@kevinsmaster5 kevinsmaster5 force-pushed the kmas-lg-13132-sp-redirect-duration branch from fbfc179 to bbe2e8a Compare May 13, 2024 16:46
@@ -1,6 +1,6 @@
require 'rails_helper'

RSpec.describe 'throttling requests', allowed_extra_analytics: [:*] do
RSpec.describe 'throttling requests' do
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@aduth is that the correct way to get this in compliance?
This bubbled up when I rebased
https://gitlab.login.gov/lg/identity-idp/-/jobs/1197662

Copy link
Member

Choose a reason for hiding this comment

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

I think this might be an issue on main, possibly from someone else's changes.

Copy link
Member

Choose a reason for hiding this comment

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

I created a pull request at #10617 which fixes this in isolation, but tl;dr is yes this is the correct way to fix the issue, though I wouldn't expect you'd need it in your pull request. If your pull request is ready to go, feel free to merge those changes, but otherwise we can handle it in #10617 and rebase your branch with the fix on main.

@kevinsmaster5 kevinsmaster5 force-pushed the kmas-lg-13132-sp-redirect-duration branch from 45287b5 to d7cbaa1 Compare May 14, 2024 11:44
@kevinsmaster5 kevinsmaster5 merged commit ade4a03 into main May 14, 2024
2 checks passed
@kevinsmaster5 kevinsmaster5 deleted the kmas-lg-13132-sp-redirect-duration branch May 14, 2024 12:10
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.

None yet

3 participants