Page MenuHomePhabricator

[lib] Introduce relyingOnAuthoritativeKeyserver constant
ClosedPublic

Authored by ashoat on Mar 3 2024, 9:06 PM.
Tags
None
Referenced Files
F3382751: D11228.diff
Thu, Nov 28, 11:50 AM
Unknown Object (File)
Oct 29 2024, 9:48 AM
Unknown Object (File)
Oct 16 2024, 2:22 AM
Unknown Object (File)
Oct 4 2024, 2:46 AM
Unknown Object (File)
Oct 4 2024, 2:46 AM
Unknown Object (File)
Oct 4 2024, 2:46 AM
Unknown Object (File)
Oct 4 2024, 2:46 AM
Unknown Object (File)
Oct 4 2024, 2:46 AM
Subscribers
None

Details

Summary

This diff starts the process of splitting usingCommServicesAccessToken into three:

  1. usingCommServicesAccessToken: flipped to true for identity service launch
  2. supportingMultipleKeyservers: whether the app works with multiple keyservers, which relies on Tunnelbroker to sync data (eg. keyservers and users) and the backup service to restore that data
  3. relyingOnAuthoritativeKeyserver: whether the app needs to have a cookie with the authoritative keyserver in order to be considered logged in

These will all be separate launch processes, so I figured it made sense to have three separate constants.

In this diff I introduce relyingOnAuthoritativeKeyserver. In the following diff I'll update reducers to use relyingOnAuthoritativeKeyserver to decide whether to log the user out during a SET_NEW_SESSION with cookieInvalidated.

Depends on D11227

Test Plan

I used this test plan for the whole stack: https://gist.github.com/Ashoat/75ab690d5c53cdd68a51b02e03e27c58

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

This revision is now accepted and ready to land.Mar 5 2024, 6:30 AM
lib/components/keyserver-connection-handler.js
180 ↗(On Diff #37761)

I should add relyingOnAuthoritativeKeyserver here too

Add relyingOnAuthoritativeKeyserver condition to logout when we fail to auth with authoritative keyserver