SKU credential (in VPN) should be cached indefinitely until redeemed or expired

[bsclifton]

Description

A pool of SKU credentials are issued for the client when they connect over account.brave.com. These credentials are each good for 24 hours (each having their own 24 hour time window) and have a boolean tracking them for if they're "spent".

The credentials are considered "spent" after they are presented. In the VPN code, that happens here:
https://github.com/brave/brave-core/blob/12648373743b58d164a00e0c2a4e00f76e2ab9cd/components/brave_vpn/browser/brave_vpn_service.cc#L719-L776

I believe we're missing a case for when Guardian VPN authorization fails for some reason (service outage, etc). When the credential is presented (above), we need to cache this (save to local state). We need to re-use that until:

• we authorize successfully with Guardian VPN
  OR
• the date in expires_at (GMT) is reached

Right now, I believe we're not handling failure scenario for Guardian VPN API. This may not even be a problem with Guardian- the customer themselves may have an outage during the call. We then try to present the credential AGAIN - and there are no unspent credentials that meet the current time window.

• STR for checking normal(success) behavior

1. Complete purchase and refresh
2. Click vpn button and see main panel is shown
3. If fetching subs creds is failed, brave_vpn.subscriber_credential will have skus_credential value.
   When not failed, brave_vpn.subscriber_credential will have credential value.

[simonhong]

Set QA/NO because it seems very difficult to simulate subs credential fetching failure.

[stephendonner]

Set QA/NO because it seems very difficult to simulate subs credential fetching failure.

Even blocklisting/routing to 127.0.0.1 connect-api.guardian.com (or whatever the appropriate hostname is)?

[bsclifton]

@stephendonner to simulate, we had to edit the code - so that the first call fails on purpose (ex: it goes to a bad URL). The second call then would work.

We can't make connect-api.guardian.com non-routable because it'll fail before it gets to the authentication portion (ex: when it gets server list). I wish there was an easier way to test - but we both did compile/test/verify locally. We can always hop on a call and do a live debugging

[simonhong]

@stephendonner @bsclifton Although it's difficult to test with official build, we can check there is no failure.
If brave://local-state has brave_vpn.subscriber_credential.credential key, all good.
If it has brave_vpn.subscriber_credential.skus_credential key, we failed to get subs credential from guardian.

1. Complete purchase and refresh
2. Click vpn button and see main panel is shown
3. If fetching subs creds is failed, brave_vpn.subscriber_credential will have sksu_credential value.
   When not failed, brave_vpn.subscriber_credential will have credential value.

[kjozwiak]

@stephendonner @bsclifton Although it's difficult to test with official build, we can check there is no failure. If brave://local-state has brave_vpn.subscriber_credential.credential key, all good. If it has brave_vpn.subscriber_credential.skus_credential key, we failed to get subs credential from guardian.

1. Complete purchase and refresh
2. Click vpn button and see main panel is shown
3. If fetching subs creds is failed, brave_vpn.subscriber_credential will have sksu_credential value.
   When not failed, brave_vpn.subscriber_credential will have credential value.

@stephendonner @bsclifton labelled as QA/Yes for now due to the above comment from @simonhong. However, if this is still hard to verify even with the above, please feel free to slap the QA/No. I'll leave this in the 1.49.x milestone till ~Thursday before moving it into 1.50.x. At that point, I doubt we'll get another C111 or need a 1.49.x HF.

[kjozwiak]

Moving this into 1.50.x as per the above as I doubt we'll get another C111 update or require a 1.49.x HF as 1.50.x is scheduled for next week. If we do end up needing a 1.49.x, we'll move the above back into a new 1.49.x milestone.

[stephendonner]

This affects macOS, too, but a check on Windows should suffice, here.

[stephendonner]

Verification PASSED using

Brave	1.50.110 Chromium: 112.0.5615.49 (Official Build) (64-bit)
Revision	bd2a7bcb881c11e8cfe3078709382934e3916914-refs/branch-heads/5615@{#936}
OS	Windows 10 Version 22H2 (Build 19045.2788)

Steps:

1. installed 1.50.110
2. launched Brave
3. loaded account.brave.software (dev, as a stopgap)
4. entered throwaway email from temp-mail.org to create new account
5. logged back in via link in email
6. purchased Brave VPN & Firewall
7. confirmed I saw You have active credentials loaded! green banner/messaging
8. clicked on the VPN button in the browser toolbar
9. clicked to toggle to Connected
10. loaded brave://local-state
11. examined the value for brave.vpn.subscriber_credentials

Confirmed via both brave://local-state as well as general usage that Brave VPN credentials are working as expected 👍

just-purchased state	Connected	brave://local-state