search

department-of-veterans-affairs / va-mobile-app

"If VA were a company, it would have a flagship mobile app."
https://department-of-veterans-affairs.github.io/va-mobile-app/
15 stars 2 forks source link

BUG - sev-2 - iOS - Unable to log in on older iPad (maybe related to older version of Safari?) #8271

Open TKDickson opened 6 months ago

TKDickson commented 6 months ago

What happened?

On my iPad 10.2 (8th gen) running iOS 14.6 and Safari (whatever the **** version of Safari correlates with that) , I'm unable to log in - something goes awry when handing off from the web back to mobile (see video).

I pinged the FE team to see what info would be useful from Charles, and the response was:

Version of Safari (or whatever the default browser is + version) AUTH_SIS_ENDPOINT=https://staging.va.gov/sign-in AUTH_SIS_TOKEN_EXCHANGE_URL=https://staging-api.va.gov/v0/sign_in/token AUTH_SIS_TOKEN_REFRESH_URL=https://staging-api.va.gov/v0/sign_in/refresh AUTH_SIS_REVOKE_URL=https://staging-api.va.gov/v0/sign_in/revoke

So -- most of that information, I don't have. The staging-api.va.gov/v0/sign_in/token API call does NOT happen, the sequence of API calls ends pretty much right before that one would be called. The refresh call and the revoke call also only happen post login.

The very last API traffic that's recorded (before I'm dumped back on the mobile app & not logged in) is staging-api.va.gov/v0/sign-in. So that full response is down in the Charles proxy collapsible, below.

Specs:

Steps to Reproduce

Desired behavior

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See [Bug Tracking](https://department-of-veterans-affairs.github.io/va-mobile-app/docs/QA#issue-severity) for details on severity levels

Linked to Story

Screen shot(s) and additional information

Full JSON response for services related to issue (expand/collapse) ``` HTTP/1.1 200 OK Date: Thu, 28 Mar 2024 15:11:41 GMT Content-Type: text/html; charset=utf-8 Etag: W/"af72fe16a21007a79d53f2cdf1bf5d98" Referrer-Policy: strict-origin-when-cross-origin Vary: Origin X-Content-Type-Options: nosniff X-Custom-Response-Header: eks-staging X-Frame-Options: SAMEORIGIN X-Git-Sha: 4a3d7869651c77db4d0a80f4e41f41582359c3e8 X-Github-Repository: https://github.com/department-of-veterans-affairs/vets-api X-Permitted-Cross-Domain-Policies: none X-Request-Id: ccb5c506-07b5-4cc0-a06c-37fd742da6be X-Runtime: 0.011311 X-Xss-Protection: 0 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-Frame-Options: SAMEORIGIN Cache-Control: no-cache, no-store Pragma: no-cache Content-Encoding: gzip Transfer-Encoding: chunked Connection: keep-alive ```

Ticket Checklist

Sparowhawk commented 6 months ago

@TKDickson based off the response I assume it is failing here:

if let error = error as? ASWebAuthenticationSessionError, error.code == .canceledLogin { reject("000", "RNAuthSession Cancelled", nil) } else if let error = error { reject("001", "RNAuthSession Error", error) } else if let url = callbackUrl { resolve(url.absoluteString) }

This is in our native module for iOS. Meaning that either the login was canceled(don't think this is the case) or there was an error from the upstream service in which event we cannot login.

It should log these two analytics await logAnalyticsEvent(Events.vama_exchange_failed()) if (error.status) { await logAnalyticsEvent(Events.vama_login_token_fetch(error.status)) }

The error code for vama_login_token_fetch should be 000 or 001 if that is what is going on

TKDickson commented 6 months ago

@Sparowhawk I'm running this on my physical device (and my local setup is shot) so I can't tell if we're logging those analytics/what we're logging for them.

Looking at what I can see on firebase, we have plenty of vama_exchange_failed logged, but not a single vama_login_token_fetch error status. Which could be a problem with the analytic itself, or with firebase/setup.

Is there something else I can look for?

TKDickson commented 5 months ago

Our data analyst (in a very low-priority fashion) is seeing if he can pull the error codes mentioned above, from production data/BigQuery.

bischoffa commented 5 months ago

@TKDickson @ajsarkar28 should this be a Sev-2 or Sev 3. Its been open for over a month and has no movement. Sev-2 should be work the following sprint they were identified given its not I am curious if this should be a Sev-3 in addition to the fact its low prioritiy for Data to look into.

OVezeamama commented 5 months ago

@Sparowhawk Can you look at @TKDickson second to last comment to verify if the event trigger is being captured? In particular is the error status working?

bischoffa commented 5 months ago

@Sparowhawk can you look at the above comment 
CC @ajsarkar28  @TKDickson

Sparowhawk commented 4 months ago

@TKDickson @bischoffa

both analytics are called when we handle this function handleTokenCallbackUrl, which only returns to us if our webview encounters a url that starts with this vamobile://login-success?

if it doesn't start with that then they aren't logged at all

If there is an error we log that the exchange fails

we only log the vama_login_token_fetch error if the error object we receive has a status. If it doesn't then we don't log it.

So with @TKDickson comment of us having exchange errors and not having status errors it means that the error we are receiving doesn't have a status associated.

So the analytic likely needs to be updated to get further data

Sparowhawk commented 4 months ago

the only issue is we don't know exactly what is available in the error object we receive to send to firebase or any other data beyond that. Not sure if Therese can see what the error response is from Charles, but we likely would need some direction or be able to recreate this locally, which I am currently unsure how we would do that

bischoffa commented 4 months ago

Moving ticket to blocked given Analytics is needed

bischoffa commented 2 months ago

@ajsarkar28 @OVezeamama is this something that is on the backlog to be reviewed given this Sev-2 has been open for awhile. Also wasn't sure if this is part of Global's future bug squash sprint coming up.

TKDickson commented 2 months ago

@ajsarkar28 confirmed this morning that we have not logged a single instance of the vama_login_token_fetch error in production. Therefore, I've written up a sev-2 bug issue that we SHOULD be logging them when relevant (#9119), have marked that ticket as blocking this one, and am bringing that ticket to global grooming today.

TKDickson commented 2 months ago

whoops. @bischoffa meant to tag you as an FYI on the comment above

TKDickson commented 2 months ago

@ajsarkar28 was able to pull some initial numbers for vama_exchange_failed.

I also sliced it by deviceName (ex. Samsung galaxy vs. iPhone11) and OS Version but it wasn't useful since the error is happening everywhere Also, there's no additional error information

The lack of additional error information means we need the additional error details (to be added in response to blocking ticket #9119) to keep this moving.

timwright12 commented 5 days ago

@TKDickson is looks like https://github.com/department-of-veterans-affairs/va-mobile-app/issues/9119 is complete now, are we able to work on this? @ajsarkar28 or is it still blocked by analytics?

TKDickson commented 5 days ago

@timwright12 you'd have to ask FE if there's enough information to investigate at this point, so looping in @dumathane as a proxy. We've fixed all of the things that were not providing information previously/all known blockers, at the very least.